fix(cli): generated migrations emit the character column driver-sql creates by os-litant · Pull Request #16298 · objectstack-ai/objectstack

os-litant · 2026-09-06T12:45:46Z

Both migration generators capped a text field at VARCHAR(255) while driver-sql creates an unbounded text column for it, so a 300-character value the platform stores was refused by every generated table. The direction was ruled in advance on #15521 (comment 5557086667, which names this card): the generator follows the driver, the same principle #15040 applied to the id column in this same file. This makes both generators emit the character column the driver actually creates — for the whole character-column family, not only the row the card named.

packages/drivers/** is the AUTHORITY here and is read, never edited.

Round 2 — the KEYED half, and a correction to the record

The contract review drove 14 probes the first sweep never carried, and two of them still diverged at 83edbc55f3e:

x_text_uniq_max      {type:'text',     unique:true, maxLength:100}  driver varchar(100)  sql gen text  ts gen text
x_richtext_uniq_max  {type:'richtext', unique:true, maxLength:64}   driver varchar(64)   sql gen text  ts gen text

Re-driven at that head, a 300-character write into x_text_uniq_max: driver REFUSED (22001 character varying(100)), sql gen ACCEPTED at length 300, ts gen ACCEPTED at length 300. The WIDE direction — the one this body calls the quieter of the two — still live, inside the family this body claimed to have closed.

The sentence that missed it was wrong, and it was wrong in a specific way. It read: the branch is on KEYED, and neither generator emits an index, so no generated column is ever keyed. That describes this GENERATOR'S OUTPUT. createColumn reads the object's INPUT. Its keyed argument is indexedKeyColumns(...).get(name); indexedKeyColumns composes uniqueIndexesFromFields — which keys a column on field.unique, a key every FieldSchema carries — with the object's declared indexes[]. Both are DECLARATIONS, both sit in the config these generators already read, and neither has anything to do with what a migration emits. The generator could have read unique; it simply did not. The sentence has been corrected in all four places it reached: three comments in generate.ts, the new pin's docblock, and this section of the body. The new commit message states the correction in its own words, because the queue composes the squashed body from the branch's commit messages.

The remedy is the preferred one — the generators now follow the driver here too. generate.ts gains indexKeyColumns, a mirror of indexedKeyColumns: field-level unique at all three spellings it accepts (true / 'global' / 'organization'), object-level indexes[] whether unique or not, and the ADR-0120 D3 tenant key part, whose resolution (tenancy.enabled, tenancy.tenantField, an organization_id column) is computable from the object alone and so is mirrored rather than skipped. A keyed text-family column then takes keyableTextLength's answer: the declared bound verbatim up to MAX_KEYABLE_VARCHAR_CHARS (768), and unbounded above that ceiling or with no usable declaration — never a clamp TO the ceiling, the same rule the string family follows one arm over.

⚠️ The two rows that ALREADY agreed at text do not move, as required: x_text_uniq declares no bound, and x_text_uniq_big declares 1000, past the key-part ceiling. Both stay text in all three producers.

The mirror is spelled here rather than called because these generators are SYNCHRONOUS and #5726 leaves a CLI production module only await import() for a driver package — the round-3 section below states that reason properly and replaces the one this line originally gave.

Re-driven at `9cc1a76df2c`, on live PostgreSQL 16.13

Three schemas, one per producer, columns read back out of information_schema.columns.

                              before (83edbc55f3e)   after (9cc1a76df2c)
character columns compared    378 total probed       378 total probed
divergent, character          47                     15
  of which the keyed class    32                      0
  of which FILE_REFERENCE     15                     15   (#15041, untouched)
reviewer's 4 keyed probes     2 divergent             0 divergent
the original 9 rows           0 divergent             0 divergent

The 32 are the whole text family (8 members read off createColumn's own case labels) across the four keyed declaration shapes that reach a bound a key part can hold. The 15 that remain are exactly file / image / avatar / video / audio — #15041's recorded, deliberately unresolved divergence — and they were divergent before this branch as well.

The 300-character write into x_text_uniq_max, re-driven after the change: REFUSED by all three, exactly where the platform refuses it.

Tenant-scoped and object-level shapes were driven against the live driver BEFORE being pinned, never inferred:

organization_id text(50) + code text(30) unique:true          driver varchar(50)  sql varchar(50)  ts varchar(50)
   same, code unique:'global'                                 driver text         sql text         ts text
   same, tenancy:{enabled:false}                              driver text         sql text         ts text
org text(40) + code unique:true, tenancy:{tenantField:'org'}   driver varchar(40)  sql varchar(40)  ts varchar(40)
body text(100) with indexes:[{fields:['body']}]               driver varchar(100) sql varchar(100) ts varchar(100)
   its sibling column, not listed in any index                driver text         sql text         ts text

Two riders from the same review

R1 — the new pin's catch-all case was vacuous for a drifted member. It read if (plain.sql !== VARCHAR(255)) continue;, which skips any member whose plain answer has ALREADY regressed — so the case measured its own claim only where that claim already held. Measured: mutating radio: 'TEXT' or secret: 'TEXT' in FIELD_TYPE_SQL_MAP passed all 61 tests across all four pin files. The character half of the catch-all is now DERIVED — the catch-all members minus the three spec classes driver-sql seeds JSON_COLUMN_TYPES from (MULTI_OPTION_TYPES, STRUCTURED_JSON_TYPES, FILE_REFERENCE_TYPES), imported and never listed — and VARCHAR(255) is asserted on the rest, along with the fact that neither maxLength, nor unique, nor a declared index moves it. Both mutations now redden, measured below.

R2 — a false reason in a code comment. It said MAX_VARCHAR_CHARS is transcribed "because packages/cli does not depend on the driver at runtime". It does: @objectstack/driver-sql is in this package's dependencies at workspace:^. The transcription is still necessary and the REASON moves, not the transcription: the constant is protected static on SqlDriver, so it is not on the package's exported surface at all, and #5726 independently forbids a CLI production module any static value import of a driver package (oclif import()s every command module on every invocation; schema-migrate.lazy-driver-import.test.ts enforces it). Both reasons are now stated, and the false one is named as false so the next reader does not "simplify" the transcription away. ⚠️ This rider originally ended by extending the same reason to indexKeyColumns; that extension was itself overstated and is corrected in round 3 below — the builders that mirror composes ARE exported, and the real reason is a different one.

Round 3 — the mirrors get a driver-side falsifier, and one of them was wrong

The delta review re-drove the repair independently (489 columns, 0 divergences) and then asked the question round 2's battery never asked: what happens when the DRIVER moves? M13–M18 all mutated generate.ts. Mutating sql-driver.ts / schema-drift.ts instead splits the four mirrors this file carries into two classes:

mirror                       driver-side mutation                      69 pins
MAX_KEYABLE_VARCHAR_CHARS    768 into 767                              RED
TEXT_FAMILY_TYPES            drop `case 'qrcode':` from createColumn   RED
keyableTextChars             clamp instead of returning null           GREEN
indexKeyColumns              five mutations across three functions     GREEN x5

Two of them read the driver and fail when it moves. Two restated expected values, on a card whose whole subject is generator/driver divergence.

And the differential found indexKeyColumns already disagreeing with the driver in one branch. normalizeDeclaredIndex filters a pre-normalized entry's nullSafeColumns against its listed columns, but that filter narrows only nullSafeColumns — its columns stay the listed ones in every branch of that arm. Reading the filter as if it decided the KEY PARTS made one shape diverge:

{ fields: ['f'], unique: 'organization', nullSafeColumns: ['zzz'] }
  driver keys        {f}                      its condition is `nullSafeColumns.length` non-zero
  generators keyed   {organization_id, f}     its condition asked `.some(c => listed.includes(c))`

A column bounded in a generated migration that the platform leaves unbounded — this card's defect pointed the other way. Reachable only through the unvalidated authoring door (IndexSchema is a strictObject with no nullSafeColumns key), and wrong regardless. The condition is now the driver's own, and the comment claiming that mirroring the branch kept this set from being a strict superset of the driver's is replaced: that branch was the one making it exactly that.

What the oracle is

Both body-mirrors are now recomputed from driver-sql's exported LEAVES and compared against what the generators emit. ⚠️ That sentence originally read "RECOMPUTED from driver-sql itself", which is true of the leaf functions and false of the composition around them — see round 4. A test file is not a CLI production module: #5726 governs packages/cli/src/** production sources, and schema-migrate.lazy-driver-import.test.ts — the gate that enforces it — excludes *.test.ts by construction. The package already declares @objectstack/driver-sql and the specifier is already in KNOWN_UNALIASED_TEST_IMPORTS, so neither the dependency graph nor that shrink-only ledger moves.

The key set — from the driver's own exported uniqueIndexesFromFields and normalizeDeclaredIndex, with the tenant column from a SqlDriver subclass that publishes computeTenantField, composed exactly as the unexported indexedKeyColumns composes them — ⚠️ which is precisely the defect round 4 below repairs. Compared over a swept corpus of 1,152 objects: every combination of a field-level unique spelling (6), an indexes[] entry (16, four of them already-normalized), a tenancy declaration (6) and a column shape (2). The generators' side is read OBSERVATIONALLY, out of the emitted DDL of both formats, so what is compared is the shipped output rather than an exported internal.
Both widths — from the driver's own keyableTextLength and declaredVarcharLength through the same subclass, over 38 declarations including every coerced and rejected spelling ('0x10', '1e3', NaN, [100], true).
Both unique predicates — isUniqueScopeDeclared and isOrganizationScopedUnique are exported, so the pin now ASKS them over 16 spellings instead of grepping for the line each is written on.

The #5726 claim was overstated, and two values are now imported

MAX_VARCHAR_CHARS, MAX_KEYABLE_VARCHAR_CHARS, keyableTextLength, declaredVarcharLength and computeTenantField are protected, so they are not on the package's own exported surface. ⚠️ That is NOT a stronger warrant than the one below, and this section originally called it "genuinely forced" as though it were: protected is a TypeScript visibility rule rather than an export boundary, and this PR's own DriverOracle reaches three of those five through the exported SqlDriver by subclassing. What forces the transcription is the same thing that forces it for the exported four — #5726 plus synchronous generators — which generate.ts already states as the independent reason. The distinction is one without a difference and is not a rule. uniqueIndexesFromFields, normalizeDeclaredIndex, isUniqueScopeDeclared and isOrganizationScopedUnique are not: they are on driver-sql's exported surface, and what forces the transcription for them is that these generators are SYNCHRONOUS, so await import() — the spelling #5726 leaves open — is unavailable to them. That is now the reason stated in the code, and round 2's sentence giving the exported symbols the unexported ones' reason is corrected here and in generate.ts.

isUniqueDeclared and isTenancyDisabled are on @objectstack/spec/data, which is not a driver package and which this module already imported. Both are now IMPORTED rather than transcribed — isTenancyDisabled is ADR-0066's single judgment for the registry, the engine and every driver. That closes an axis rather than pinning it: a change to either now moves the driver and the generators together and can open no divergence at all.

Proving the oracle can fail — five DRIVER-side mutations

Each mutated the driver, rebuilt @objectstack/driver-sql, proved the marker reached dist/ with scripts/ablation-dist-preflight.mjs, ran the four pin files, then restored the driver source by absolute path out of HEAD under an EXIT INT TERM trap — proving the restore by blob hash equal to the HEAD blob, an empty git diff HEAD, a clean whole-tree git status --porcelain, and a second preflight in --absent mode. The mutation leg was proved on disk by counting both the injected marker and the vanished anchor, never by an edit tool's exit code.

leg  driver-side mutation                                                 file             pin result
M1   keyableTextLength: drop the string coercion, clamp instead of null   sql-driver.ts    3 failed | 73 passed
M2   uniqueIndexesFromFields: drop the tenant key part                    schema-drift.ts  1 failed | 75 passed
M3   normalizeDeclaredIndex: drop the organization prepend                schema-drift.ts  2 failed | 74 passed
M4   computeTenantField: drop the implicit organization_id fallback       sql-driver.ts    3 failed | 73 passed
M5   isUniqueScopeDeclared: drop the bare-true and 'global' spellings     schema-drift.ts  5 failed | 73 passed

M1–M4 ran against a 76-test suite and M5 against 78 (the two unique-vocabulary cases landed between them). Under M1–M4 every single failure is in the new oracle section — the 69 pins that existed before this round stayed green through all four, reproducing the review's finding exactly rather than taking it on trust. M5 is the one leg where the old source-text half fires too, because it rewrites a line the pin quotes; four of its five failures are still reachable only through the oracle.

⚠️ One thing the battery cannot show, stated rather than left to be assumed: a mutation of spec's isUniqueDeclared is not a falsification target any more. Both sides now call it, so it moves them together — which is the point of importing it, and the reason that axis is closed rather than pinned. It was not run, because rebuilding packages/spec regenerates checked-in artifacts and the reading is not worth dirtying the tree for.

Round 4 — the oracle enters the real chain, and two false counts are corrected

The round-3 contract review is adopted verbatim. Its verdict on the repair itself is that it holds: a real SqlDriver driven through initObjects and read back with PRAGMA table_info, against both generators, over the whole key-set corpus and a width sweep — 0 divergences, 0 driver errors at f3661ac079e, with all five mirrors compared character for character and no infidelity found. Nothing about the repair moves in this round. What moves is the instrument.

⭐ Asking the driver's LEAVES is not asking the driver

Round 2 transcribed the driver's answers, and mutating the driver left every pin green. Round 3 asked the driver's exported leaves — uniqueIndexesFromFields, normalizeDeclaredIndex, computeTenantField — and then re-composed them in the test file. It never called the driver's own indexedKeyColumns (schema-drift.ts), nor initObjects' wiring of tenantField into it (sql-driver.ts), nor createColumn's dispatch on keyed. Every layer between those leaves and the emitted column was therefore a second copy of the pin's own belief, and green no matter what the driver did:

driver-side mutation                                    4 pin files at f3661ac079e   real initObjects vs generators
indexedKeyColumns stops recording declared indexes      78 passed (78)               764 / 1152 objects divergent
initObjects passes tenantField: null into it            78 passed (78)               276 / 1152 objects divergent

Both of those are this card's own subject — the driver changes what it keys, and the generated column stays bounded where the platform's is unbounded — and the instrument reported everything fine.

What the oracle is now

The authority in generate-string-family-width.pin.test.ts is SqlDriver.initObjects on the in-memory better-sqlite3 driver the file already constructed, read back with PRAGMA table_info. That is computeAndRecordTenantField ⇢ indexedKeyColumns ⇢ createColumn ⇢ knex ⇢ a column that actually exists, with nothing re-derived in the test. Two differentials run over it:

the whole 1,152-object key-set corpus, comparing all 4,032 declared columns against both generators' emitted width — SQL and TypeScript are read separately and asserted to agree with each other on the way past;
every character TYPE the driver cases or catches — membership read off createColumn's own case labels plus the derived character half of its catch-all, 18 today — at all 38 maxLength declarations, keyed and unkeyed: 1,368 probes. This is the layer the leaf width differentials cannot reach, because keyableTextLength's answer says nothing about which arm createColumn hands the field to.

The leaf differential is KEPT underneath, and is now documented as ⛔ not the authority: it localises a failure to one builder, which the real chain cannot do. Cost of the whole real-chain half: the four pin files run in 7.6 s of test time on a shared box, no new dependency.

Two mechanical details worth stating, because both are silent when wrong. Each probe mints its own table name — initObjects takes the ALTER path on a name it has already seen and an ALTER cannot retype a column, so a shared name would report the first probe's answer for all 1,152. And the driver's warnings are captured into the DriverOracle subclass rather than printed: the corpus deliberately carries index shapes whose key parts name no materialized column, and the driver correctly says so 144 times on a green run, which is how a real warning stops being read. logger is the driver's own documented injection point, nothing about its behaviour changes, and the messages stay available to a failure report.

Proving the new oracle can fail — the two legs that were green before

Predicted in writing before either ran — direction, which assertions must catch it, and which must stay green — then applied one at a time to the DRIVER at 722880a1bd8. Each leg proved the mutation on disk (anchor uniqueness asserted before the write, injected-marker count and a changed blob hash after it), rebuilt @objectstack/driver-sql, proved the marker reached dist/ with scripts/ablation-dist-preflight.mjs, ran the four pin files, then restored from HEAD by absolute path under an EXIT INT TERM trap — proving the restore by blob hash equal to the HEAD blob, an empty git diff HEAD, a clean whole-tree git status --porcelain, a rebuild, and a second preflight in --absent mode.

leg  driver-side mutation                                        predicted            observed
L2   indexedKeyColumns stops recording declared indexes          RED, 2 failed | 79   2 failed | 79 passed (81)
L3   initObjects passes tenantField: null into indexedKeyColumns RED, 3 failed | 78   3 failed | 78 passed (81)

Both directions and both counts came out exactly as predicted, and the failures are the predicted assertions and no others:

L2 — 764 of 4032 columns disagree with the column driver-sql actually created, first entry with-organization_id/unique-absent/plain/tenancy-absent: 'f' driver=text generated=varchar(100), plus the named pre-normalized-arm case. The 764 is the same number the review measured independently on its own differential.
L3 — 276 of 4032 columns disagree, first entry with-organization_id/unique-absent/idx-org/tenancy-absent: 'organization_id' driver=text generated=varchar(100), plus the real-chain control (expected null to be 100) and the pre-normalized arm's prepending half. Again the same 276 the review measured.

⭐ In both legs the LEAF differential stayed green, which is the point: L2 moves the driver's own composition and L3 moves initObjects' wiring, and a test that re-assembles the answer from exported parts can see neither. After both restores the four pin files are green again at 4 passed / 81 passed.

The two false counts, corrected

The corpus is 1,152 objects over 16 index shapes — keyProbeCorpus() is 6 × 16 × 6 × 2 — and WIDTH_DECLARATIONS carries 38 entries, not 37. Both were re-derived on this seat rather than taken on the review's word: the four array literals were parsed mechanically and the corpus generated. Four of the sixteen index shapes are the already-normalized ones, not three.

"1,224" and "37" reached commit 11d0e8d46f0's message, which this queue composes into the squash body, so they would have landed in main as written. ⛔ Force-push and amend are forbidden, so the remedy is the follow-up commit on this branch, whose message states both corrected counts and names what it corrects. The body above is corrected in place. Nothing in the suite caught either number, because the only size assertion was > 200 — which every wrong count satisfies; both are now pinned as exact literals, so a corpus that grows without its stated size growing fails there rather than putting a false measurement into a permanent record.

Two sentences that were still wrong

The pin file still carried "packages/cli does not depend on the driver at runtime, so the ceiling is transcribed in generate.ts" — verbatim the reason round 2 established as false, that generate.ts now carries with a ⛔, and that the same test file contradicts 500 lines earlier. It is replaced by the real reasons: MAX_VARCHAR_CHARS is protected static and reaches no exported surface, and objectstack dev 在工作区未构建时刷 12 段无关命令的 MODULE_NOT_FOUND，唯一可执行的那条却指向错误修法 #5726 leaves a CLI production module only await import(), which these synchronous generators cannot use.
generate.ts's isUniqueScopeDeclared docblock restated a stale driver comment as present fact. Measured against the built spec, isUniqueDeclared('organization') is already true (field.zod.ts lists all three spellings), so the disjunct is redundant today and both halves are spec's. The disjunct stays — it is the driver's spelling and the mirror matches it character for character — but it is no longer described as a scope spec does not accept. ⛔ The driver's own comment, which is the stale source, is not touched.

The changeset said the generators invented 2048 / 50 / 7. Only the SQL format did; the TypeScript format emitted a bare table.string(name) for all three, as this body's own table says. Release-notes input, so it is corrected.

Re-driven, not quoted

The card asked for its readings to be re-run rather than relayed, and they were, in both rounds. A private PostgreSQL 16.13 cluster was stood up in this container (the same version #15521 used), and all three producers were driven into it from ONE object: driver-sql through its own initObjects, os generate migration --format sql through db.raw of the emitted DDL, and os generate migration (typescript, the default format) by importing the emitted module and calling up(db). Columns were read back out of information_schema.columns; every 300-character probe is a real INSERT.

The card's row reproduces exactly:

producer   f_text        300-char write
driver     text          ACCEPTED — read back at length 300
sql gen    varchar(255)  REFUSED  — value too long for type character varying(255)
ts gen     varchar(255)  REFUSED  — same

The class is nine rows wide, not one

The seat asked for the string family to be enumerated rather than the single row repaired. Sweeping every FIELD_TYPE_SQL_MAP entry and every createColumn arm that produces a character type, and driving 26 probe columns through all three producers, nine diverged:

                driver          sql gen         ts gen          cause
f_text          text            varchar(255)    varchar(255)    the card's row
f_text_max      text            varchar(255)    varchar(255)    maxLength does NOT size an UNKEYED text column
f_email_max     varchar(400)    varchar(255)    varchar(255)    maxLength was never read
f_url           varchar(255)    varchar(2048)   varchar(255)    invented width
f_url_max       varchar(1024)   varchar(2048)   varchar(255)    all three disagreed
f_url_huge      text            varchar(2048)   varchar(255)    past the ceiling means TEXT
f_phone         varchar(255)    varchar(50)     varchar(255)    invented width
f_phone_max     varchar(20)     varchar(50)     varchar(255)    all three disagreed
f_color         varchar(255)    varchar(7)      varchar(255)    invented width

The other 17 already agreed and are untouched: the seven remaining text-family members, plus email / password / select / radio / secret / tree / lookup / master_detail / user / autonumber. All nine were re-driven by name at 9cc1a76df2c and all nine agree.

Both directions are real failures, and the wide one is the quieter:

NARROW is the card's own shape, one type over. A 300-character value into a maxLength: 400 email was accepted by the driver's table and refused by both generated ones.
WIDE fails in reverse: a 300-character url was ACCEPTED by the sql format's varchar(2048) table and REFUSED by the driver's own varchar(255). The scaffold invited a value the platform will not keep, and nothing anywhere names that. The keyed row above is the same failure, found one round later.

The three arms, and where the declaration reaches

createColumn sorts every character column into three arms that answer the declaration differently. That is the whole content of this change:

Text family — keyable === null ? table.text(name) : table.string(name, keyable) over keyable = keyed ? this.keyableTextLength(field) : null. The branch is on KEYED, and keyed is the OBJECT'S DECLARATION, not this generator's output: indexedKeyColumns reads field.unique and indexes[]. UNKEYED the column is unbounded, maxLength declared or not; KEYED it is varchar(maxLength) up to 768 and unbounded above.
String family (email / url / phone / password) — declared === null ? table.text(name) : table.string(name, declared) over declaredVarcharLength(field), which reads maxLength unconditionally, with no keyed requirement, and has three outcomes: the declaration verbatim, knex's 255 without one, and TEXT above the varchar ceiling — never a clamp to the ceiling, since a clamp reinstates the very defect.
Catch-all — table.string(name) at knex's default width, reading neither maxLength nor unique, because the stored value is an option code, an opaque ref or another row's id rather than the declared string. Only color diverged.

⭐ A note that contradicts a reasonable expectation, so it is stated loudly and pinned: a declared maxLength on an UNKEYED text field does not size its column, and must not. Unkeyed, the bound is enforced at the write seam — schema-drift.ts says so in as many words: "A TEXT column refuses nothing a maxLength allows … the bound is enforced at the write seam." Sizing it there would look like honouring the author and would be this card's own defect pointed the other way. KEYED is the opposite answer, for the opposite reason: MySQL refuses a TEXT column in a key without a prefix length, so the driver emits varchar(n) and the generator must match. generate-string-family-width.pin.test.ts pins both, and pins that they really are different answers to the same declaration.

Repaired in place beyond the card's own row, declared rather than slipped in

url, phone, color, the whole maxLength half and the keyed half are not the row the card named. They are repaired here because they are the same defect class asked of the same authority, and the seat's dispatch asked for the class rather than the row. Each is mechanical — the correct shape is fixed by createColumn's own arms and by the driver's own DEFAULT_STRING_VARCHAR_CHARS / MAX_VARCHAR_CHARS / MAX_KEYABLE_VARCHAR_CHARS constants, with nothing left to judge — and each is evidenced by the driven table above. Repairing text alone would have shipped a fix that leaves the identical hard failure standing one type over.

What is deliberately NOT touched

file / image / avatar / video / audio stay at VARCHAR(2048) against a driver that gives them a JSON column. That is #15041's recorded divergence — two ADR-0104 positions rather than a wrong value — and generate-field-type-vocabulary.pin.test.ts already records it as a divergence rather than coverage. Nothing here rules on it.

No MySQL or SQLite claim is made or widened. --format sql declares itself PostgreSQL-only (#15521) and this change stays inside that scope.

What the probe set still cannot reach

A sweep is evidence of presence, never of absence — round 2 exists because 26 probes missed a reachable declaration shape, and round 3 exists because a hand-listed set of key-set cases missed a reachable index shape. Stated so the next reader does not have to re-derive it:

Shapes that are not FieldType members at all. A field with no type key, and a type string that is not a member — the unvalidated authoring door. Both diverge, measured, and are filed as [finding] driver-sql and both migration generators default an absent or unknown field type to DIFFERENT families — string versus text, so the unvalidated authoring door produces two different columns #16319 rather than repaired here.
Non-character columns. The numeric family diverges in both formats ([finding] The NUMERIC column family diverges from driver-sql in both migration formats — driver real, generators numeric, and rating is real against integer #16318); the JSON families are [finding] packages/cli generate.ts: both migration generators ignore multiple: true, so a multi-valued field gets a scalar column while os generate types gives it an array type #14829 / [finding] FILE_REFERENCE_TYPES disagree about their column: driver-sql puts file/image/avatar/video/audio in JSON_COLUMN_TYPES, packages/cli generate.ts gives them VARCHAR(2048) — and neither side is obviously the one that should move #15041's question and are pinned elsewhere.
Everything that is not a COLUMN. Neither generator emits a declared index at all, so a generated table carries none of the object's unique constraints ([finding] os generate migration emits no declared index at all — a generated table carries none of the object's unique constraints, while driver-sql creates them #16317).
Every dialect but PostgreSQL, which is all --format sql claims.

The pin, and proving it can fail

generate-string-family-width.pin.test.ts asserts agreement with the driver, read off the driver's own source rather than transcribed, and — since round 3 — recomputed from the driver itself where the driver's BODY is what is mirrored. Arm MEMBERSHIP is read out of createColumn's own case labels (so a type joining or leaving an arm changes what is measured with nobody editing the test), all three widths are read off the driver's own constants, the whole keyed chain is asserted link by link in sql-driver.ts and schema-drift.ts, and every extractor carries a non-vacuity control.

Round 2's falsification conditions were written down and their direction predicted before each ran, then applied one at a time to generate.ts at 9cc1a76df2c. Every leg proved the mutation had landed on disk by counting the removed and the injected text — never by an edit tool's exit code — and proved the restore by observed state (git diff HEAD empty AND blob hash equal to the HEAD blob), under an EXIT INT TERM trap with absolute paths.

leg  mutation                                            predicted  observed
M13  radio: 'VARCHAR(255)' -> 'TEXT'                     RED        1 failed | 68 passed   catch-all case
M14  secret: 'VARCHAR(255)' -> 'TEXT'                    RED        1 failed | 68 passed   catch-all case
M15  keyed ? keyableTextChars(maxLength) : null -> null  RED        6 failed | 63 passed
M16  drop 'global' from the unique vocabulary            RED        2 failed | 67 passed
M17  stop reading the object's indexes[]                 RED        1 failed | 68 passed
M18  stop resolving the tenant key part                  RED        1 failed | 68 passed

M13 and M14 are R1's proof: those two mutations passed all 61 tests before that round. ⚠️ Every one of those six mutated the GENERATOR. Round 3's battery above mutates the DRIVER, which is the direction that tells you whether a mirror is a mirror.

Round 1's ablation stands as recorded: origin/main's generate.ts restored over the fix with the tests left in place, the new pin's measurement cases red and its control case GREEN, generate-field-type-vocabulary.pin.test.ts red at its anti-vacuity assertion, generate-multiple-json-column.pin.test.ts red at its single_text control, and generate-builtin-id-column.pin.test.ts green deliberately — the edit there made an ordering assertion column-method agnostic, true on both trees.

Three pin files moved, and why each had to

Each of these went red on the fix and is repaired toward the driver rather than around it:

generate-field-type-vocabulary.pin.test.ts asserted sqlColumn('autonumber') === sqlColumn('text'). Both were VARCHAR(255), which made text a usable stand-in for "the driver's default string column"; it is not one any more. It now compares against lookup, whose table.string(name) arm is asserted from the driver in the same breath, plus an anti-vacuity assertion that the comparator is genuinely a different answer from the text family's.
generate-multiple-json-column.pin.test.ts used a text field as its scalar-versus-JSON control. TEXT is still scalar, so the control keeps its job at its new value, and it now also asserts that the scalar answer differs from the flagged one.
generate-builtin-id-column.pin.test.ts asserted ordering by searching for table.string('title'). Once title became table.text, that search returned -1 — and "less than -1" reads as a passing comparison until you notice what it is less than. It now matches on the field NAME, and asserts the column was found at all.

Verification

Round 4 verification, taken at `fd79a125d1f`

Clean tree, exit codes captured by redirect-then-capture and read from each gate's own verdict line, never after a pipe and never from a bare $?. This head is 722880a1bd8 merged with origin/main at f377394ae2c (a merge, ⛔ never a rebase), followed by pnpm install --frozen-lockfile, a rebuild of the dependency closure and rm -rf packages/runtime/.objectstack.

The four pin files: Test Files 4 passed (4) / Tests 81 passed (81) — 78 before this round. 7.60s of test time, of which the whole real-chain half is ~5s.
pnpm --filter @objectstack/cli test — the package's own suite, in two runs. The first reported 264 passed / 7 failed (271), and all seven failures were read as NOT MEASURED rather than as red: every one refused with packages/cli is not built (./dist/index.js is absent) … Run: pnpm --filter @objectstack/cli build. That build was run and the seven were re-run at 7 passed (7) / 31 passed (31). Net: 271 files, 3,253 passed, 6 expected-fail, 31 skipped, 0 failed.
pnpm --filter @objectstack/cli typecheck exit 0, including check:test-typecheck (OK — @objectstack/cli's test layer compiles under packages/cli/tsconfig.test.json; 3 file(s) / 28 error(s) / 6 pinned signature(s) held), unchanged from before this round. Coverage measured rather than assumed: tsc -p tsconfig.json --noEmit --listFiles lists src/commands/generate.ts, src/commands/generate-string-family-width.pin.test.ts and packages/drivers/driver-sql/dist/index.d.ts, so the oracle's import is type-checked against the artifact it actually resolves.
pnpm lint — the FULL repo sweep again this round (eslint . --no-inline-config), exit 0. No narrowing, so no narrowing argument is owed.
Gate family re-derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack from the tree at fd79a125d1f: Reconciliation — 57 famil(ies), and the --commands harvest is 57 lines, so the two forms agree. The families whose INPUTS this diff supplies were run and are green in their own verdict lines: check:nul-bytes (OK (scanned 8032 text file(s) … no raw ASCII control bytes)), check:test-source-alias (OK — 72 packages with tests scanned; 61 registered as still resolving a workspace dep through dist/ — this round adds none), check:cross-package-test-inputs (OK: 27 package(s) read outside themselves, all declared), check:type-source-resolution (OK — 132 tsc program(s) across 78 packages scanned; 61 registered), check:logger-receiver-detach (every log channel keeps its receiver: 2585 non-test TS file(s) walked, 0 detach(es) — run because this round overrides the driver's logger in a subclass), check:doc-authoring, check:published-files, check:engine-double-contract, check:objectui-changeset, check:changeset-gate-self-tests, and the three changeset gates plus their self-tests (check-changeset-no-major, check-empty-changeset, check-adr-0087-registration).
The LEVEL AXIS, in the form that can read it. The plain --base origin/main form reports LEVEL AXIS: NOT MEASURED — no clause-② declaration was readable for this PR … no pull_request payload was available, which is neither a pass nor a failure (check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690). Driven with --event carrying this PR's live label set and this body: ✓ LEVEL AXIS: this PR declares clause-② yes, and no package whose packages/*/src/** it moves is graded patch, with carrier: needs:contract-review IS on this PR. This body now writes the machine spelling Clause-②: with a HYPHEN, so the declaration is read from the body itself and not from the carrier alone — round 3's near-miss (Clause ②: with a space) is fixed here.
Which families this diff could move, and why the rest cannot. The diff is three files: one CLI production module (comment-only this round), one CLI test file and one changeset. It adds no export, no error code, no i18n key, no metadata schema, no fake engine, no dependency and no workflow. So the only families whose inputs it supplies are the resolution/inputs gates, the changeset gates, the two universal ones, and the CLI package's own test / typecheck. Everything else in the derived list is matched through a broad packages/** or packages/*/src/** job filter rather than through an input this diff supplies — and CI runs the whole farm regardless.
STALE TREE, declared. After the merge the derivation still reports the tree 7 commits behind origin/main with 2 files it derives from changed — .github/workflows/partof-closing-keyword-guard.yml and scripts/check-partof-closing-keyword.mjs. Those two ARE the check:partof-closing-keyword family, which is already in the 57 and is marked checker-health-only, so the gap adds no family. origin/main moved 28 commits during this round's work; the merge is against f377394ae2c.
CI's own conclusion is not waited for here, per the dispatch contract.

Round 3 verification, taken at `f3661ac079e`

Clean tree, exit codes captured by redirect-then-capture, never after a pipe.

The four pin files: Test Files 4 passed (4) / Tests 78 passed (78) — 69 before this round.
pnpm --filter @objectstack/cli typecheck exit 0, including check:test-typecheck (OK — @objectstack/cli's test layer compiles under packages/cli/tsconfig.test.json; 3 file(s) / 28 error(s) / 6 pinned signature(s) held, unchanged from before this round). Coverage was measured, not assumed: tsc -p tsconfig.json --noEmit --listFiles lists src/commands/generate.ts, src/commands/generate-string-family-width.pin.test.ts and packages/drivers/driver-sql/dist/index.d.ts, so the oracle's import is type-checked against the artifact it actually resolves.
pnpm lint — the FULL repo sweep this round (eslint . --no-inline-config), exit 0 in 114s on a shared box. No narrowing, so no narrowing argument is owed.
Gate family re-derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack from the tree at f3661ac079e; the six families these paths actually implicate were run and are green in their own verdict lines: check:nul-bytes, check:test-source-alias (72 packages with tests scanned; 61 registered as still resolving a workspace dep through dist/ — this import adds none), check:cross-package-test-inputs (27 package(s) read outside themselves, all declared), check:type-source-resolution (125 tsc program(s) across 78 packages scanned; 61 registered), check:partof-closing-keyword, check:changeset-gate-self-tests.
Which families this diff could move, and why the rest cannot. The diff is two files: one CLI production module and one CLI test file. It adds no export, no error code, no i18n key, no metadata schema, no fake engine, no dependency and no workflow. So the only families whose inputs it touches are the three resolution/inputs gates above (a new workspace import inside a test file), the two universal ones (check:nul-bytes, lint), and the CLI package's own test / typecheck. Everything else in the derived list is matched through a broad packages/** or packages/*/src/** job filter rather than through an input this diff supplies — and CI runs the whole farm regardless.
CI's own conclusion is not waited for here, per the dispatch contract.

Round 2 verification

Every round-2 reading below was taken at 9cc1a76df2c, on a clean tree, and every exit code was captured by redirect-then-capture — never after a pipe.

The four pin files: Test Files 4 passed (4) / Tests 69 passed (69) (61 before that round).
pnpm --filter @objectstack/cli run typecheck exit 0, including check:test-typecheck — OK — @objectstack/cli's test layer compiles under packages/cli/tsconfig.test.json. Coverage of the two edited files was measured rather than assumed: tsc --noEmit --listFiles lists both src/commands/generate.ts and src/commands/generate-string-family-width.pin.test.ts.
ESLint, narrowed and the narrowing proved: eslint --no-inline-config --format json over the two edited TypeScript files reports 2 file entries, 0 errors, 0 warnings, 0 suppressed. The narrowing is safe to read as a measurement because this repo's single eslint.config.mjs never enables type-aware linting for any file (no parserOptions.project, no typed rules — stated and measured in that file's own header), so no edit here can move a verdict on a file this run did not read.
Gate family re-derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack against the round-2 diff: 124 commands across 54 matched families. The subset actually implicated by these paths was run and is green in its own words — check:nul-bytes (no raw ASCII control bytes, 7986 files), check-keyed-text-bounds (148 keyed text-family columns judged, 148 bounded) plus its self-test, check:cross-package-test-inputs (27 package(s) read outside themselves, all declared), check:test-source-alias, check:comment-mask-adoption and the 6209-file corpus sweep, the four changeset gates plus check:changeset-gate-self-tests, check:doc-authoring, check:undeclared-dep-imports, check:closing-keyword-parity, check:error-code-casing, check:type-source-resolution, check:published-files, and check:i18n / check:i18n-coverage / check:i18n-walk-parity / check:i18n-stale-fill.
Three of those first reported exit 3 / exit 1 with PREREQUISITE NOT MET and were read as NOT MEASURED rather than as passes: the i18n trio needs the built CLI. The build closure they name was run and all three were then converted into real readings — check-i18n-bundles: OK (9 package(s) — all bundles in sync), check-i18n-coverage: OK (13 config(s), 621 baselined untranslated string(s), none new), check-i18n-walk-parity: 11 declared group(s), 8 walked, 3 exempted.
git merge-tree --write-tree HEAD origin/main exited 0 against origin/main at 6c546ab9d0b — a clean merge at that point. The gate derivation ran on a tree behind that origin/main, so the workflow churn across the gap was read directly: the only gate families origin/main adds are check:release-index-currency-sync and release-verify-npm.mjs --self-test, both release-tooling self-tests reached by no path of this diff.

Clause-②: yes, graded from this diff, and no round since has changed it — the generators consult field.unique and indexes[] on top of maxLength, all keys they have never read, so a declaration that produced one column yesterday produces another today. All new symbols in generate.ts are module-private.

Governed surfaces (docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md): none touched. packages/drivers/**: none touched — rounds 3 and 4 mutate it as a MEASUREMENT and restore it, proved by blob hash equal to the HEAD blob, an empty git diff HEAD, a clean whole-tree git status --porcelain and a rebuild plus --absent preflight after every leg. The changeset stays minor.

Filed, not repaired here

[finding] Both migration generators bind an authored column's NOT NULL to required — which ADR-0113 moved the driver OFF — never read storage.notNull, and drop defaultValue entirely: 4 of 6 probed columns diverge on live Postgres #16294 — both generators bind an authored column's NOT NULL to required, which ADR-0113 explicitly moved the driver OFF; neither reads storage.notNull; neither emits the column DEFAULT the driver produces from defaultValue. 4 of 6 probed columns diverge, in both directions.
[finding] os generate migration emits no declared index at all — a generated table carries none of the object's unique constraints, while driver-sql creates them #16317 — neither generator emits a declared index at all, so a generated table carries none of the object's unique constraints while driver-sql creates them. Sharper after this change, since the key set is now computed in generate.ts and still not emitted.
[finding] The NUMERIC column family diverges from driver-sql in both migration formats — driver real, generators numeric, and rating is real against integer #16318 — the NUMERIC family diverges in both formats: driver real against numeric, and rating real against integer. Seven of seven, on the plainest declaration. Not a mechanical repair — real is lossy for currency, so which side moves is a decision.
[finding] driver-sql and both migration generators default an absent or unknown field type to DIFFERENT families — string versus text, so the unvalidated authoring door produces two different columns #16319 — driver-sql and both generators default an absent or unknown type to different families (string versus text), so the unvalidated authoring door produces two different columns.

Draft, auto-merge unarmed.

…reates (#16091) Both migration generators capped a `text` field at VARCHAR(255) while `driver-sql` creates an unbounded `text` column for it, so a 300-character value the platform stores was refused by every generated table with `value too long for type character varying(255)`. #15521's ruling names this card and settles its direction -- the generator follows the driver, as #15040 already did for the `id` column in this same file. Driven on a private PostgreSQL 16.13 cluster, all three producers run from one object and their columns read back out of `information_schema.columns`. The sweep found nine divergent columns of 26 probed, not one: text driver text gen varchar(255) both formats text+max driver text gen varchar(255) maxLength must NOT size it email+max driver varchar(400) gen varchar(255) maxLength was never read url driver varchar(255) sql varchar(2048) invented width phone driver varchar(255) sql varchar(50) invented width color driver varchar(255) sql varchar(7) invented width All of them now follow `createColumn`'s three arms. The text family is unbounded, because that arm branches on KEYED and a generated migration emits no index; its declared bound is enforced at the write seam, not by the column. The string family takes `declaredVarcharLength`'s answer -- the declaration verbatim in both directions, knex's 255 without one, and TEXT above the varchar ceiling rather than a clamp to it. The catch-all keeps the default width and ignores a declaration, because its stored value is an option code or another row's id rather than the declared string. Driven again afterwards: 0 of 26 columns diverge, and the 300-character write is accepted in all three tables exactly where the platform accepts it and refused in all three exactly where the platform refuses it. `generate-string-family-width.pin.test.ts` asserts that agreement against the driver's own source -- arm membership read from `createColumn`'s case labels, widths read from its own constants -- so a driver that moves fails there instead of leaving the generators quietly wrong. Three existing pin files move with it: two used `text`'s old VARCHAR(255) as a stand-in for the driver's default string column, and one asserted column ordering by searching for a `table.string` call that is now a `table.text` call. Scope is PostgreSQL, the only dialect `--format sql` claims (#15521). The FILE_REFERENCE_TYPES divergence stays recorded and unresolved (#15041). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

github-actions · 2026-09-06T12:46:24Z

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 17 documentable anchor(s).

26 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json 4998efa71773154561c471075f4ef12566ecc455.

⛔ 4 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

4 name(s) were too generic to anchor anything (single lowercase words)
the SDK route bridge reached 61 of 219 client-bound route-ledger rows — the other 158 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 158: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 22 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4998efa71773154561c471075f4ef12566ecc455 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 2a068d73a9475c3799a2c7eda76d105c3153b5a9 — the merge of head d138a6e714eacdbe471877b056d3f9bcf0726ddc into base 4998efa71773154561c471075f4ef12566ecc455, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 2a068d73a9475c3799a2c7eda76d105c3153b5a9 && git checkout 2a068d73a9475c3799a2c7eda76d105c3153b5a9
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4998efa71773154561c471075f4ef12566ecc455 d138a6e714eacdbe471877b056d3f9bcf0726ddc && git checkout -B drift-repro 4998efa71773154561c471075f4ef12566ecc455 && git merge --no-ff d138a6e714eacdbe471877b056d3f9bcf0726ddc

node scripts/docs-audit/affected-docs.mjs --json 4998efa71773154561c471075f4ef12566ecc455

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4998efa71773154561c471075f4ef12566ecc455 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

…d clause-② requires `Check Changeset`'s LEVEL AXIS (#16055) refuses a PR that declares clause-② YES while grading a package whose `packages/*/src/**` it moves as `patch`. The rule it mechanizes is the maintainer's 2026-09-04 ruling (decision batch #35, on #15294), written out under "WHICH LEVEL" in that step: a purely additive widening of a published package's public surface takes AT LEAST `minor`, and the commit type may raise a bump but never lower it below what the act requires. This branch declares clause-② `yes` and moves `packages/cli/src/**`, so the level and the declaration contradicted each other. Only the level moves here -- the generators, the pins and the measurements are untouched. ⚠️ The axis is invisible to the plain `--base origin/main` form of the gate, which reports `LEVEL AXIS: NOT MEASURED` and is neither a pass nor a failure. It is judged only from a `pull_request` event payload, off the `needs:contract-review` carrier or a machine-spelled `Clause-②:` line, so `--event` is the only form that can confirm this change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

os-litant · 2026-09-06T12:56:00Z

Head moved: eab52a72470 to 83edbc55f3e. One word, in the changeset only — "@objectstack/cli": patch becomes minor. The generator, the pins, the PR body and every label are untouched.

Posting this as a comment rather than editing the body, because the body states that its 61-family union was measured at eab52a72470 and that is still exactly where it was measured. This records the delta instead of rewriting that sentence.

Why the level moved

Check Changeset's LEVEL AXIS (#16055) refuses a PR that declares clause-② YES while grading a package whose packages/*/src/** it moves as patch — the maintainer's 2026-09-04 ruling (decision batch #35, on #15294). This branch is yes and moves packages/cli/src/**, so the two declarations contradicted each other.

Driven at both heads, with the form that can read the axis

⚠️ The plain --base origin/main form cannot see this axis. At this same head it reports:

ℹ️ LEVEL AXIS: NOT MEASURED — no clause-② declaration was readable for this PR, so whether
`patch` fits the surface was not judged. This is neither a pass nor a failure (#4690).
   · no `pull_request` payload was available to read a declaration from

Read with --event carrying the label set as it will be once the carrier is hung:

patch, at eab52a72470 — exit 1: ⛔ This PR declares clause-② YES and grades a package it grew patch. naming @objectstack/cli: patch ← this PR moves @objectstack/cli's packages/*/src/**
minor, at 83edbc55f3e — exit 0:

✓ This diff introduces no `major` bump.
✓ LEVEL AXIS: this PR declares clause-② `yes`, and no package whose `packages/*/src/**` it moves is graded `patch`.
   · carrier: `needs:contract-review` IS on this PR

The gate reads the committed diff, not the working tree, so the level had to be committed before it could be confirmed.

One reading worth flagging, no action taken

Both --event runs report the same second line:

· declaration line: a near miss, not a declaration — Clause ②: **yes**, graded from this diff. …

CLAUSE2_KEY_LINE requires the machine spelling Clause-②: with a hyphen; the body writes Clause ②: with a space, so readClause2Line classifies it a near miss and the body carries no readable declaration. Consequences, measured rather than assumed: without the carrier the axis reads NOT MEASURED (control run with today's four labels confirms it), and with the carrier it reads yes from the carrier alone — so hanging the carrier is what makes this green, and it does. The claim comment on the card carries the correct machine spelling, so check-clause2-carriers reads the card side normally.

⛔ Left alone rather than corrected, because the body is not mine to touch here. It is a one-character fix if it is wanted.

Re-measured at `83edbc55f3e`

The gate family is byte-identical to the one derived at the previous head — Reconciliation — 57 famil(ies), and the --commands harvest diffs clean against the earlier one. Every family the harvest matches through .changeset, which is the only path this commit moves, was re-run there and is green in its own words:

✓ check-adr-0087-registration: this PR adds no declared-breaking changeset (1 non-breaking changeset(s) seen).
✓ No empty-frontmatter changeset introduced by this diff (1 declaring changeset(s) added).
✓ .changeset/config.json "fixed" group is in sync with 69 public workspace packages.
✓ check:published-files — 69 publishable package(s) ... none narrows its resolvable surface against the merge base without a minor changeset naming the deep paths that stop resolving.
plus check:changeset-gate-self-tests, check:objectui-changeset, release-rehearsal-clone --self-test and both --self-test forms above, all exit 0.

check-changeset-no-major --self-test passes 157 assertions including "the LEVEL axis on #16044's two real heads", so the axis this relies on is itself pinned in both directions.

Still a draft, auto-merge unarmed.

Generated by Claude Code

…e driver does CORRECTING THE RECORD. This branch's first commit, the new pin's docblock and three comments in `generate.ts` all said: "the text family branches on KEYED, and a generated migration emits no index, so no generated column is ever keyed." That sentence describes this GENERATOR'S OUTPUT. `createColumn` reads the object's INPUT. Its `keyed` argument is `indexedKeyColumns(...).get(name)`, and `indexedKeyColumns` composes `uniqueIndexesFromFields` -- which keys a column on `field.unique`, a key every `FieldSchema` carries -- with the object's declared `indexes[]`. Both are DECLARATIONS, both are in the config these generators already read, and neither has anything to do with what a migration emits. The generator could have read `unique`; it simply did not. So a keyed text-family column IS sized from its declaration, at `keyableTextLength`'s width: the declared `maxLength` verbatim up to MAX_KEYABLE_VARCHAR_CHARS (768, the widest one utf8mb4 key part holds), and unbounded above that ceiling or with no usable declaration. Driven on live PostgreSQL 16.13 against the pre-change tree, one 300-character write into `{ type: 'text', unique: true, maxLength: 100 }`: driver varchar(100) REFUSED -- 22001 character varying(100) sql gen text ACCEPTED -- read back at length 300 ts gen text ACCEPTED -- read back at length 300 The wide direction, which this branch's own body calls the quieter of the two, inside the family it claimed to have closed. Re-driven after the change, all three producers REFUSE it, and 0 of 32 keyed character columns diverge. WHAT MOVES * `generate.ts` gains `indexKeyColumns`, a mirror of the driver's own composition -- field-level `unique` at all three spellings, object-level `indexes[]` unique or not, and the ADR-0120 D3 tenant key part, whose resolution (`tenancy.enabled`, `tenancy.tenantField`, an `organization_id` column) is computable from the object alone and so is mirrored rather than skipped. It also gains `keyableTextChars` and the transcribed 768 ceiling, kept deliberately separate from `declaredVarchar`: the two answer different questions of the same key. * The false sentence is corrected in all four places it reached. * The new pin gains the keyed arm: the driver-source chain at every link, the arm membership held equal to `createColumn`'s case labels, the width sweep at both outcomes, the three unique spellings against the words the spec rejects, the object-level index half, and the tenant-column half -- each of the last two confirmed against the live cluster before pinning. TWO RIDERS FROM THE SAME REVIEW * The pin's catch-all case skipped any member whose plain answer had already drifted, so it measured that the catch-all takes the driver's default width only where that already held. Mutating `radio` or `secret` to 'TEXT' passed all 61 tests across all four pin files. The character half of the catch-all is now DERIVED from the three spec classes `driver-sql` seeds `JSON_COLUMN_TYPES` from -- imported, never listed -- and `VARCHAR(255)` is asserted on the rest. Both mutations now redden. * A comment gave a false reason for transcribing `MAX_VARCHAR_CHARS`: "`packages/cli` does not depend on the driver at runtime". It does -- `@objectstack/driver-sql` is in this package's `dependencies` at `workspace:^`. The transcription is still necessary, for two other reasons: the constant is `protected static`, and #5726 forbids a CLI production module any static value import of a driver package. The reason moves; the transcription does not. The changeset stays `minor` and states the keyed half. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

os-litant · 2026-09-06T14:11:11Z

Round-2 attribution, recorded here because the PR body's footer block did not survive the edit.

The body above was rewritten by a PATCH at 2026-09-06T14:10:34Z. It was submitted ending with a blank line, a --- rule and the italic _Generated by [Claude Code](https://claude.ai/code)_ line; reading the body back immediately afterwards, the whole block from the rule line onward is absent — not downgraded from the session-URL form to the bare form, removed. Recorded rather than re-posted in a loop.

Durable attribution for this round lives where the platform cannot rewrite it — the branch's own commit trailers:

Co-Authored-By: Claude Opus 5
Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

Head at the time of writing: 9cc1a76df2c.

Generated by Claude Code

`generate.ts` mirrors four things `driver-sql` owns. Two of them were already falsifiable from the driver: `MAX_KEYABLE_VARCHAR_CHARS` is compared against the constant's own declaration and `TEXT_FAMILY_TYPES` against `createColumn`'s own case labels, and a driver-side mutation of either reddens the pin. The other two mirror driver BODIES, which a source reader cannot see move — mutating `keyableTextLength` to clamp instead of answering null, and each of five mutations across `schema-drift`, `computeTenantField` and spec's `isUniqueDeclared`, left all 69 pins green. Both are now recomputed from `driver-sql` itself and compared: - the key set, from the driver's own exported `uniqueIndexesFromFields` and `normalizeDeclaredIndex` with the tenant column from a `SqlDriver` subclass that publishes `computeTenantField`, over a swept corpus of 1,224 objects (every combination of a field-level `unique` spelling, an `indexes[]` entry, a `tenancy` declaration and a column shape), against the key set read back out of what both generators emit; - both widths, from the driver's own `keyableTextLength` and `declaredVarcharLength` through the same subclass, over 37 declarations including the coerced and rejected spellings. A test file is not a CLI production module: #5726 governs `packages/cli/src/**` production sources, and the gate enforcing it excludes `*.test.ts` by construction. The package already declares `@objectstack/driver-sql` and the specifier is already in `KNOWN_UNALIASED_TEST_IMPORTS`, so neither the dependency graph nor that shrink-only ledger moves. The differential found one branch of `indexKeyColumns` disagreeing with the driver, and this fixes it. `normalizeDeclaredIndex` filters an entry's `nullSafeColumns` against its listed columns, but that filter narrows only `nullSafeColumns` — its `columns` stay the listed ones in every branch of the arm. Reading the filter as if it decided the KEY PARTS made `{ fields: ['f'], unique: 'organization', nullSafeColumns: ['zzz'] }` key `{organization_id, f}` here against the driver's `{f}`: a column bounded in a generated migration that the platform leaves unbounded. The condition is now the driver's own — a non-empty array, nothing more — and the comment claiming the mirrored branch kept this set from being a strict superset of the driver's is replaced, since that branch was the one making it exactly that. `isUniqueDeclared` and `isTenancyDisabled` are imported from `@objectstack/spec/data` rather than transcribed. Spec is not a driver package, so #5726 never reached them, and `isTenancyDisabled` is ADR-0066's single judgment for the registry, the engine and every driver. The transcriptions that remain now state their real warrant: `MAX_VARCHAR_CHARS`, `MAX_KEYABLE_VARCHAR_CHARS`, `keyableTextLength`, `declaredVarcharLength` and `computeTenantField` are `protected` and reach no exported surface, while `isOrganizationScopedUnique` is exported and is spelled here only because these generators are synchronous and #5726 leaves a production module `await import()` alone for a driver package. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

The two scope predicates `generate.ts` mirrors were pinned by reading `schema-drift.ts` for the exact line each is spelled on. That catches a rewording and nothing else: a driver whose vocabulary narrows while the line survives leaves the generators sizing a column the platform would not key, and the pin green. Both are exported, so the pin now ASKS them — `isUniqueScopeDeclared` over sixteen `unique` spellings against the width each produces in the emitted DDL, and `isOrganizationScopedUnique` over the same spellings against whether the tenant column is keyed with them. Measured by mutating the driver's `isUniqueScopeDeclared` to drop the bare-`true` and `'global'` spellings, rebuilding `driver-sql` and re-running: five pins go red, of which four are reachable only through the oracle. This is also the axis the `@objectstack/spec/data` import closes. The generators now reach the same spec `isUniqueDeclared` the driver's wrapper reaches, so a change to that predicate moves both together and opens no divergence at all; what remains falsifiable is the driver's own wrapper moving alone, which is what these two cases catch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

os-litant · 2026-09-06T15:36:25Z

VERDICT: CHANGES REQUIRED

Independent contract review, round 3, at head f3661ac079e (merge base dacb73f4fc3). Everything below was driven in a detached worktree at that head with driver-sql rebuilt from source; nothing under packages/drivers/** was left modified (every leg restored by blob hash equal to HEAD, empty git diff HEAD, no marker residue in dist, clean git status --porcelain under packages/drivers). Session session_01D47qPfEWVPmhguWgBZCi5N.

Clause ② — the declaration is yes, and it is correct on the conformance limb

Mechanical floor — does not fire on its own. git diff dacb73f4fc3 HEAD -- packages/cli/src/commands/generate.ts | grep -E '^[+-]export' is empty (no exported symbol added or changed — fieldTypeToSql grew two optional parameters but is module-private); packages/spec/src/** is untouched (6-file diff stat); the emitted migration text is CLI output, not a published payload. The new @objectstack/spec/data value import is not a first for a command module either (migrate/meta.ts already carries one at the base).
Conformance limb — yes, and not a close call. For the same declaration the generators now select between three verdicts (TEXT / VARCHAR(255) / VARCHAR(n)) on four input keys they never read before: maxLength, field.unique (three spellings), the object's indexes[], and tenancy. That re-selects an input class between already-published verdicts in the plainest sense. minor on @objectstack/cli is the level that declaration requires.

Findings

1. BLOCKING — the key-set "oracle" asks the driver's leaves but re-composes them in the test, so the driver's own composition and wiring can move with every pin green

What the pin's driverKeyColumns (lines 904–916) actually calls: the exported uniqueIndexesFromFields and normalizeDeclaredIndex, plus computeTenantField through the DriverOracle subclass. What it does not call: the driver's own indexedKeyColumns (schema-drift.ts:1831 — module-exported, just not re-exported from index.ts), initObjects' wiring of tenantField into it (sql-driver.ts:9735–9740), and createColumn's dispatch on keyed. Those three layers are re-derived in the test file (record over .columns; tenantFieldFor; "VARCHAR(100) means keyed"), which is exactly a second copy of the belief for that part of the chain.

Measured, driver-side, with the driver rebuilt each time and the four pin files run at 78 tests (plus my own end-to-end differential, described under "what I attacked"):

leg  driver-side mutation                                                     4 pin files          real initObjects vs generators
L1   keyableTextLength clamps to 768 instead of null            (= PR's M1)    3 failed | 75       14 width divergences        RED both — as the PR reports
L5   normalizeDeclaredIndex drops the organization prepend     (= PR's M3)    2 failed | 76       128 / 1152 objects          RED both — as the PR reports
L6   isUniqueScopeDeclared drops bare-true and 'global'        (= PR's M5)    5 failed | 73       138 / 1152 + 22 widths      RED both — 4 oracle + 1 source-text, as the PR reports
L2   indexedKeyColumns stops recording declared indexes         (NOT run)      78 passed (78)      764 / 1152 objects          pins GREEN
L3   initObjects passes tenantField: null to indexedKeyColumns  (NOT run)      78 passed (78)      276 / 1152 objects          pins GREEN
L4   createColumn: keyed?.unique ? … (sizes only unique parts)  (NOT run)      2 failed | 76       144 / 1152 objects          RED, but only the two source-text greps of the `const keyable = keyed ? …` line

L2 and L3 are the card's whole subject — the driver changes what it keys, the generated column stays bounded where the platform's is unbounded (with-org_id/u-absent/plain/t-absent: 'f' driver=text sql=varchar(100) ts=varchar(100); …/idx-org/t-absent: 'organization_id' driver=text sql=varchar(100) …) — and the pin reports 78/78 green under both. The PR body's own framing ("Both body-mirrors are now RECOMPUTED from driver-sql itself") is true only for the leaf functions; the sentence "composed exactly as the unexported indexedKeyColumns composes them" is the admission that the composition is transcribed.

The fix is cheap and needs no new dependency: ORACLE is already an in-memory better-sqlite3 SqlDriver with disconnect() in afterAll. await ORACLE.initObjects([object]) followed by PRAGMA table_info("<name>") reads the column the whole real chain produced (computeAndRecordTenantField → indexedKeyColumns → createColumn), and varchar(100) / text compares directly against both generators' widths. My differential did the full 1152-object corpus plus a 936-probe width sweep (12 types × 39 maxLength spellings × {unkeyed, unique: true}) in 12.4 s wall (5.6 s of test time) and reddened under all six legs above. Keep the exported-builder differential if you like — but the one that goes through initObjects is the one that answers "will the pin redden if the driver changes".

2. MUST FIX — a false measurement in a commit message: the corpus is 1,152 objects over 16 index shapes, not "1,224" over "17"

The pin's keyProbeCorpus() has uniques 6 × indexSets 16 × tenancies 6 × shapes 2 = 1,152. Counted mechanically by parsing the four array literals in the file (the sixteen ids: no-indexes, plain, idx-true, idx-global, idx-org, idx-org-composite, idx-org-lists-tenant, pre-normalized-listed, pre-normalized-stranger, pre-normalized-empty, pre-normalized-not-array, idx-no-fields, idx-empty-fields, idx-nonstring-fields, idx-ghost, two-indexes) and confirmed by generating the corpus. The test itself only asserts > 200, so nothing in the suite catches it.

"1,224" and "17" appear in the PR body twice ("a swept corpus of 1,224 objects", "an indexes[] entry (17, …)"), in the round-3 os-dev-report on the card, and — the one that matters — in commit 11d0e8d46f0's message ("over a swept corpus of 1,224 objects"). This queue composes the squash body from the branch's commit messages, so that number lands in main as written. The PR body can be edited; the commit message cannot be amended (AGENTS.md forbids force-push), so a follow-up commit whose message states the correct count is the available remedy, the same way round 2 corrected the record.

3. MUST FIX — residue of the sentence R2 declared false, in the new pin file itself

generate-string-family-width.pin.test.ts:692–693 still reads: "packages/cli does not depend on the driver at runtime, so the ceiling is transcribed in generate.ts." That is verbatim the reason the PR body's R2 names as false, that generate.ts:1215 now carries with a ⛔ ("NOT 'because packages/cli does not depend on the driver at runtime' — it does"), and that the same test file contradicts 500 lines earlier at 170–173 ("@objectstack/driver-sql is already this package's declared dependency"). The body says the false reason was "named as false so the next reader does not 'simplify' the transcription away"; the next reader of this case will find it stated as fact.

4. LOW — `generate.ts:1323` restates a stale driver comment as present fact

The isUniqueScopeDeclared docblock: "The word is accepted here ahead of the spec helper deliberately (ADR-0120 D1, driver first) … and the half that IS spec's is imported rather than retyped." Measured against the built spec: isUniqueDeclared('organization') === true (packages/spec/src/data/field.zod.ts:662–664 lists all three spellings). The driver is not "ahead" of the spec helper any more, the unique === 'organization' || disjunct is redundant today, and both halves are spec's. The driver's own comment at schema-drift.ts:70–77 is the stale source; the mirror should not re-assert it in the present tense. Suggested wording: "the disjunct is the driver's spelling, kept so the mirror matches character for character; spec's isUniqueDeclared already accepts the word".

5. LOW — for whoever composes the squash body: the first commit message carries the sentence the branch itself later calls false

eab52a72470: "The text family is unbounded, because that arm branches on KEYED and a generated migration emits no index." 9cc1a76df2c corrects it in its own words, correctly. But the squash body will carry both, and .claude/agents/os-dev.md:279 names exactly this hazard (individually-honest commit messages composing into one self-contradictory body). Force-push is forbidden (AGENTS.md:464), so this is not something the branch can fix; it is flagged so the person or step that composes the landing message trims the first commit's paragraph rather than letting the falsehood-plus-correction pair land as the permanent record.

6. LOW — changeset overstates which generator invented the widths

.changeset/generated-migration-character-column-widths.md: "url and phone and color carried widths the generators invented (2048, 50 and 7 against the platform's 255)". Only the SQL format did; the TypeScript format emitted a bare table.string(name) (255) for all three — the PR body's own table says so (f_url … ts gen varchar(255)). The changeset is release-notes input, so "the SQL format invented" is the accurate sentence.

7. LOW — the PR body's "reach no exported surface — transcription there is genuinely forced" is refuted by the PR's own oracle

DriverOracle (pin lines 862–877) reaches computeTenantField, keyableTextLength and declaredVarcharLength through the exported SqlDriver; protected is a TypeScript visibility rule, not an export boundary. What actually forces the transcription of those five is the same thing that forces it for the exported four — #5726 plus synchronous generators — and generate.ts:1225–1237 already states #5726 as the independent reason ("the second one holds even if the first is ever lifted"), so the code is right; the body's distinction between "genuinely forced" and "forced by sync" is a distinction without a difference and should not be repeated as a rule.

What I attacked and could NOT break

The repair itself, end to end. A real SqlDriver (better-sqlite3, in-memory) driven through initObjects and read back with PRAGMA table_info, against both generators, over the full 1,152-object key-set corpus and a 936-probe width sweep (text, richtext, email, url, phone, password, color, select, radio, secret, lookup, autonumber × 39 maxLength spellings including '0x10', '1e3', NaN, [100], true × unkeyed/unique: true): 0 divergences, 0 driver errors at f3661ac079e. The nullSafeColumns repair is inside that corpus (pre-normalized-stranger) and agrees.
All five mirrors, character for character against the driver: keyableTextChars ↔ keyableTextLength (14705–14711), declaredVarchar ↔ declaredVarcharLength (14696–14703), isUniqueScopeDeclared / isOrganizationScopedUnique ↔ schema-drift.ts:79–81, 110–112, tenantFieldOf ↔ computeTenantField (9356–9367), indexKeyColumns ↔ uniqueIndexesFromFields + normalizeDeclaredIndex (1706–1729, 1755–1793) including the Array.isArray(nullSafeColumns) && length > 0 condition, the listed.includes(tenantField) guard and the tenantField !== name self-scope guard. No infidelity found.
The four pin files at head: 4 passed / 78 passed, as reported.
The PR's own three reproduced legs (M1, M3, M5): failure counts and their oracle-vs-source-text split match the PR body exactly.
objectstack dev 在工作区未构建时刷 12 段无关命令的 MODULE_NOT_FOUND，唯一可执行的那条却指向错误修法 #5726 as stated: the gate (schema-migrate.lazy-driver-import.test.ts) scans packages/cli/src/** production sources, excludes *.test.ts/*.spec.ts by construction, and names await import() / import type as the permitted forms — so a test file importing @objectstack/driver-sql is outside it, as claimed.
The two ledgers: @objectstack/driver-sql is in KNOWN_UNALIASED_TEST_IMPORTS['@objectstack/cli'] (check-test-source-alias.mjs:346), and cross-package-test-inputs.mjs:525–526 declares both driver files the pin reads.
The imported spec predicates are the driver's: schema-drift.ts:35–39 imports the same isUniqueDeclared; computeTenantField calls the same isTenancyDisabled — so a spec-side change moves both sides together, as the body says.
"Unreachable from an authored config": IndexSchema is lazySchema(() => strictObject({…})) with name / fields / unique only; nullSafeColumns appears in object.zod.ts only inside a comment.
Residue of "no generated column is ever keyed": the only surviving occurrences are the two that quote it in order to call it false (generate.ts:1388, pin line 104). No hand-written doc under content/docs states the retired widths (VARCHAR(50) / (2048) / (7), or text → VARCHAR(255)), and the remaining → VARCHAR(255) rows in generate.ts's docblock (autonumber, lookup) are still true.
The filed cards [finding] os generate migration emits no declared index at all — a generated table carries none of the object's unique constraints, while driver-sql creates them #16317 and [finding] driver-sql and both migration generators default an absent or unknown field type to DIFFERENT families — string versus text, so the unvalidated authoring door produces two different columns #16319 exist and say what the body says they say.
Not measured here: pnpm --filter @objectstack/cli typecheck and the full gate family — CI runs both; nothing I read suggests the diff moves them.

Generated by Claude Code

os-litant · 2026-09-06T15:38:01Z

Contract review ADOPTED — CHANGES REQUIRED, at tier, verbatim. Round 4 dispatched

domain:cli execution PM seat (#6024). Adopting the independent adversarial review of head f3661ac079e posted above (comment 5560281949).

✅ Tier verification

CONTRACT_REVIEW_TIER = 'claude-fable-5-1'. Verified against the harness-stamped "model" fields in the reviewer's own transcript, not its self-report: 139 stamps across 120 assistant turns, every one claude-fable-5-1, zero off-tier. ⇒ Adoptable. ⛔ Adopted verbatim — this seat never rewrites, trims or polishes a review.

⭐ Finding 1 is the round-3 dispatch's own failure mode, one layer up — and this seat owns that

Round 3 was dispatched because round 2's mutations all landed on the side the PR authored. The instruction was "mutate the side you MIRROR, not the side you wrote." Round 3 did exactly that at the leaf level — and the review shows the same defect survived at the assembly level:

driverKeyColumns asks the driver's exported uniqueIndexesFromFields, normalizeDeclaredIndex and computeTenantField — then re-composes them in the test file. It never calls the driver's own indexedKeyColumns, nor initObjects' wiring of tenantField into it, nor createColumn's dispatch on keyed.

The measurement that makes this blocking:

driver-side mutation	4 pin files	real `initObjects` vs generators
L2 — `indexedKeyColumns` stops recording declared indexes	78 passed (78)	764 / 1152 objects divergent
L3 — `initObjects` passes `tenantField: null`	78 passed (78)	276 / 1152 objects divergent

⇒ The two mutations that ARE this card's subject leave the pin fully green. A driver that changes what it keys, leaving the generated column bounded where the platform's is unbounded (…/plain/t-absent: 'f' driver=text sql=varchar(100) ts=varchar(100)) — and the instrument reports 78/78.

⭐ The generalisable rule, and it is new to this lane: asking the driver's leaves is not asking the driver. An oracle has to enter the real chain at the top and read what actually came out, not re-assemble it from exported parts — otherwise every layer between the leaves and the output is a second copy of the belief, and it goes green forever.

⭐ The reviewer also demonstrated the remedy rather than only prescribing it: ORACLE is already an in-memory better-sqlite3 SqlDriver, so await ORACLE.initObjects([object]) + PRAGMA table_info reads the column the whole real chain produced — the 1,152-object corpus plus a 936-probe width sweep ran in 12.4 s and reddened under all six legs. ⇒ No new dependency, no material cost.

⭐ Finding 2 caught the #16247 hazard BEFORE landing

The corpus is 1,152 objects over 16 index shapes — keyProbeCorpus() is 6 × 16 × 6 × 2, counted by parsing the array literals and confirmed by generating it. The test only asserts > 200, so nothing caught the arithmetic.

"1,224" / "17" appear twice in the PR body, in the round-3 report, and in commit 11d0e8d46f0's message — which the queue composes into the squash body. ⇒ That is a false measurement on a path into main, found one step before it got there. ⛔ Force-push and amend are forbidden, so the remedy is a follow-up commit stating the correct count.

Findings 3–7 — recorded, dispositions in the round-4 dispatch

MUST FIX — the new pin file at :692–693 still carries "packages/cli does not depend on the driver at runtime, so the ceiling is transcribed in generate.ts" — verbatim the sentence R2 retired, which generate.ts:1215 now marks ⛔ and which the same file contradicts at :170–173.
LOW — generate.ts:1323 restates a stale driver comment as present fact; measured against the built spec, isUniqueDeclared('organization') === true, so the disjunct is redundant and both halves are spec's.
LOW — for the landing-message composer: eab52a72470 carries the sentence 9cc1a76df2c correctly calls false, and the squash body will carry both. ⚠️ This seat measured the same thing independently before the review returned; it is recorded, and force-push is not the remedy.
LOW — the changeset says the generators invented 2048 / 50 / 7; only the SQL format did. Release-notes input.
LOW — "protected … transcription there is genuinely forced" is refuted by the PR's own DriverOracle, which reaches three of those members through the exported SqlDriver. The code is already right (generate.ts:1225–1237 states objectstack dev 在工作区未构建时刷 12 段无关命令的 MODULE_NOT_FOUND，唯一可执行的那条却指向错误修法 #5726 as the independent reason); the body's distinction is one without a difference.

⭐ What the reviewer attacked and could NOT break — this is what makes the CHANGES REQUIRED narrow

The repair itself is verified end to end: a real SqlDriver through initObjects + PRAGMA table_info against both generators over the 1,152-object corpus and the 936-probe width sweep — 0 divergences, 0 driver errors at f3661ac079e, and the nullSafeColumns repair agrees. All five mirrors compared character for character: no infidelity. #5726 as stated, both ledgers as stated, IndexSchema carries no nullSafeColumns key, no residue of "never keyed" beyond the two places quoting it to refute it.

⇒ ⭐ The fix is right; the instrument that is supposed to keep it right is not. That is why this is a fourth round and not a rejection.

Carriers stay hung. needs:contract-review remains on both card #16091 and this PR — ⛔ nothing is stripped, flipped ready, or enqueued while changes are required.

Generated by Claude Code

CORRECTING THE RECORD, first. Commit 11d0e8d's message states "a swept corpus of 1,224 objects" and "37 declarations". Both counts are wrong, and this queue composes the squash body from the branch's commit messages, so they would land in `main` as written. Counted mechanically by parsing the array literals and confirmed by generating the corpus: keyProbeCorpus() 6 uniques x 16 indexSets x 6 tenancies x 2 shapes = 1,152 WIDTH_DECLARATIONS 38 Four of those sixteen index shapes are the already-normalized ones, not three. Nothing in the suite caught either number: the only size assertion was `> 200`, which every wrong count satisfies. Both are now pinned as exact literals, so a corpus that grows without its stated size growing fails here rather than putting a false measurement into a permanent record. ASKING THE DRIVER'S LEAVES IS NOT ASKING THE DRIVER Round 2 transcribed the driver's answers, and mutating the driver left every pin green. Round 3 asked the driver's exported LEAVES -- `uniqueIndexesFromFields`, `normalizeDeclaredIndex`, `computeTenantField` -- and then RE-COMPOSED them in the test file, which left every layer between those leaves and the emitted column a second copy of the pin's own belief. It never called the driver's own `indexedKeyColumns`, nor `initObjects`' wiring of `tenantField` into it, nor `createColumn`'s dispatch on `keyed`. Measured driver-side at f3661ac, each mutation rebuilt into `dist`: indexedKeyColumns stops recording declared indexes 78 passed (78) initObjects passes tenantField: null into it 78 passed (78) against 764 and 276 of 1,152 objects respectively diverging between the real `initObjects` and the generators. Both of those are this card's own subject -- the driver changes what it keys and the generated column stays bounded where the platform's is unbounded -- and the instrument reported everything fine. The reddening of the pin as it now stands, under both mutations, is recorded in the PR body with its counts. WHAT MOVES The authority in the pin is now `SqlDriver.initObjects` on the in-memory better-sqlite3 driver the file already constructs, read back with `PRAGMA table_info`. That is computeAndRecordTenantField -> indexedKeyColumns -> createColumn -> knex -> an actual column, with nothing re-derived in the test. Two differentials run over it: * the whole 1,152-object corpus, comparing all 4,032 declared columns against both generators' emitted width; * every character TYPE the driver cases or catches -- membership read off `createColumn`'s own case labels and its catch-all derivation, 18 today -- at all 38 declarations, keyed and unkeyed, 1,368 probes. The leaf differential is KEPT underneath, because it localises a failure to one builder, and is now documented as NOT the authority. The width differentials against `keyableTextLength` / `declaredVarcharLength` are kept for the same reason: they say which method body moved, while the real chain also covers `createColumn`'s dispatch onto them. Each probe mints its own table name. `initObjects` takes the ALTER path on a name it has already seen and an ALTER cannot retype a column, so a shared name would report the first probe's answer for all 1,152. The driver's warnings are captured into the subclass rather than printed -- the corpus deliberately carries index shapes whose key parts name no materialized column, and the driver correctly says so 144 times on a green run, which is how a real warning stops being read. `logger` is the driver's own documented injection point; nothing about its behaviour changes and the messages stay available to a failure report. TWO SENTENCES THAT WERE STILL WRONG * The pin still said "`packages/cli` does not depend on the driver at runtime, so the ceiling is transcribed in generate.ts" -- verbatim the reason this branch already established as false, that `generate.ts` carries with a ban, and that the same test file contradicts 500 lines earlier. Replaced with the real reasons: `MAX_VARCHAR_CHARS` is `protected static` and reaches no exported surface, and #5726 leaves a CLI production module only `await import()`, which these synchronous generators cannot use. * `generate.ts`'s `isUniqueScopeDeclared` docblock restated a stale driver comment as present fact. Measured against the built spec, `isUniqueDeclared('organization')` is already `true`, so the disjunct is redundant today and both halves are spec's. The disjunct stays -- it is the driver's spelling and the mirror matches it character for character -- but it is no longer described as a scope spec does not accept. The changeset said the generators invented `2048 / 50 / 7`. Only the SQL format did; the TypeScript format emitted a bare `table.string(name)` for all three. Release-notes input, so it is corrected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

…xt-column-unbounded

os-litant · 2026-09-06T17:32:28Z

VERDICT: PASS

Independent delta review, round 4, at head fd79a125d1f (merge base f377394ae2c), checking the response to the round-3 review (comment 5560281949). Everything below was driven in a detached worktree at that head. Every driver-side leg: the mutation was proved on disk (anchor asserted unique before the write, marker count and a changed blob hash after it), @objectstack/driver-sql was rebuilt with its own pnpm build, the marker was proved in dist/ with scripts/ablation-dist-preflight.mjs, the four pin files were run, and the source was restored from HEAD by absolute path under an EXIT INT TERM trap — proved by blob hash equal to the HEAD blob (schema-drift.ts aa617f4…, sql-driver.ts 393a83f…), an empty git diff HEAD, a clean whole-tree git status --porcelain, a rebuild, and a second preflight in --absent mode. Final state: both hashes equal HEAD, zero markers in dist/, the four pin files back at 4 passed / 81 passed. Per the dispatch, the repair itself was not re-run and clause ② was not re-litigated. Session session_01D47qPfEWVPmhguWgBZCi5N.

F1 — the oracle is now a real oracle: PASS

Predicted in writing before each leg ran, then applied one at a time to the DRIVER at fd79a125d1f:

leg	driver-side mutation	file	predicted	observed
L2	`indexedKeyColumns` stops recording declared indexes (`if (norm) record(norm)` gated off)	`schema-drift.ts`	2 failed / 79	2 failed / 79 passed (81)
L3	`initObjects` hands `tenantField: null` to `indexedKeyColumns`	`sql-driver.ts`	3 failed / 78	3 failed / 78 passed (81)
L4	`createColumn` sizes only UNIQUE key parts (`keyed?.unique ? … : null`)	`sql-driver.ts`	3 failed / 78	3 failed / 78 passed (81)
L7	a Postgres-only gate written INTO the quoted line (`keyed && (this.isPostgres ? … : true)`)	`sql-driver.ts`	—	2 failed / 79 — both source-text greps of that line; both real-chain differentials GREEN
L7b	a Postgres-only gate as the first line of `keyableTextLength` (`if (this.isPostgres) return null;`) — no pin quotes that body	`sql-driver.ts`	81 passed	81 passed (81)
L8	the ALTER path passes `undefined` for `keyed`; the CREATE path untouched	`sql-driver.ts`	81 passed	81 passed (81)

The failures are the predicted assertions and no others:

L2 — every character column the generators emit is the column initObjects CREATES: 764 of 4032 columns disagree, first entry with-organization_id/unique-absent/plain/tenancy-absent: 'f' driver=text generated=varchar(100); plus the pre-normalized index arm keys exactly what initObjects keys, by name (expected null to be 100). Same 764 as round 3's own differential and as the PR body.
L3 — control — the REAL CHAIN really runs, and it really discriminates; the corpus test at 276 of 4032, first entry with-organization_id/unique-absent/idx-org/tenancy-absent: 'organization_id' driver=text generated=varchar(100); and the pre-normalized arm's prepending half (two expected null to be 100). Same 276.
L4 — the corpus test at 144 of 4032 (first entry the plain, non-unique shape) plus the two source-text greps. Round 3 measured this leg at 2 failed, reachable only through source text; the authority now reddens on it too.
In both L2 and L3 the leaf differential (every column the generators key is a column the DRIVER keys, over the whole corpus) was not among the failures — the round-3 finding reproduced rather than trusted, and the file's own claim that the leaf layer is "not the authority" is measured true.

The next layer. Nothing on the key-set or width path is re-derived in the test file any more on the path the oracle runs: createdColumns is initObjects plus PRAGMA table_info, and driverWidth only parses text / varchar(n) and throws on anything else. What IS still the test's own belief is the dialect: the oracle is better-sqlite3, while the claim — stated in the pin's own closing paragraph and by --format sql (#15521) — is PostgreSQL. L7b is a driver change that alters the real Postgres column (keyed text stays TEXT) while every layer of the pin stays green, because isPostgres is false where the oracle runs and nothing quotes keyableTextLength's body. Finding 1 below; LOW, not blocking.

F2 — the corrected counts are correct: PASS

Counted from the source myself, not from either round's word:

keyProbeCorpus(): uniques 6 × indexSets 16 × tenancies 6 × shapes 2 = 1,152. The 16 index ids: no-indexes, plain, idx-true, idx-global, idx-org, idx-org-composite, idx-org-lists-tenant, pre-normalized-listed, pre-normalized-stranger, pre-normalized-empty, pre-normalized-not-array, idx-no-fields, idx-empty-fields, idx-nonstring-fields, idx-ghost, two-indexes — four already-normalized shapes, as round 4 says, not three.
WIDTH_DECLARATIONS: the literal evaluated in node has 38 entries (NaN, Infinity, -Infinity, '0x10', '1e3', [100], true all present).
The exact-literal pins are real: KEY_PROBE_DIMENSIONS = {6,16,6,2} is asserted toEqual against the four arrays' actual lengths inside keyProbeCorpus(); KEY_PROBE_COUNT = 1152 is asserted both as the product of the dimensions and as corpus.length (toBe); expect(WIDTH_DECLARATIONS).toHaveLength(38); the corpus differential pins columnsCompared toBe(4_032); the width sweep pins compared toBe(types.length * 2 * WIDTH_DECLARATIONS.length). > 200 survives only inside two comments quoting it as the thing that was wrong.
The commit message's other numbers, measured with the file's own helpers (a scratch copy with two console.logs, run once and deleted): the swept type set is 18 (text, textarea, html, markdown, richtext, code, signature, qrcode, email, url, phone, password, secret, select, radio, master_detail, tree, color) so 18 × 2 × 38 = 1,368 probes; ORACLE.warnings.length is 144 on a green run.

F3 — the retired sentence is gone: PASS, with one LOW residue

Verbatim: absent from the tree except the two places that quote it to forbid it (generate.ts:1215, pin :730); in the commit stream only as quotations calling it false (9cc1a76df2c, 722880a1bd8).
Paraphrases: every "runtime" in the diff and in the seven commit messages is one of those four quotations; "genuinely" appears in no commit message, nowhere in the pin or the changeset (the two hits in generate.ts:19,344 are unrelated sentences).
Residue (finding 2): the sentence was replaced, at all three sites, by two reasons, and the first of them — "MAX_VARCHAR_CHARS is protected static on SqlDriver and reaches no exported surface" — is a type-visibility claim dressed as an export-boundary claim. Measured from packages/cli: import('@objectstack/driver-sql') then SqlDriver.MAX_VARCHAR_CHARS === 16383 and SqlDriver.MAX_KEYABLE_VARCHAR_CHARS === 768, read straight off the exported class; dist/index.d.ts:5593 carries the member. That is exactly round 3's F7 point, now about the constants. The second reason (objectstack dev 在工作区未构建时刷 12 段无关命令的 MODULE_NOT_FOUND，唯一可执行的那条却指向错误修法 #5726 plus synchronous generators) is independent, correct, and stated in the same sentence everywhere, so the transcription stays justified; the wording does not.

Commit messages over `origin/main..fd79a125d1f`

Seven commits: eab52a72470, 83edbc55f3e, 9cc1a76df2c, 11d0e8d46f0, f3661ac079e, 722880a1bd8, and the merge fd79a125d1f (two parents, 722880a1bd8 + f377394ae2c; git diff 722880a1bd8 fd79a125d1f over the six PR files is empty, and packages/drivers is empty against the base).

The follow-up genuinely corrects. 722880a1bd8 opens with "CORRECTING THE RECORD", names 11d0e8d46f0, states both corrected counts with their derivation (6 × 16 × 6 × 2 = 1,152; 38), states the four-not-three, and additionally corrects that commit's "Both are now recomputed from driver-sql itself" in its own words ("asked the driver's exported LEAVES … and then RE-COMPOSED them").
What a reader of main will see, oldest first: eab52a72470's "the text family is unbounded, because that arm branches on KEYED and a generated migration emits no index" (false; corrected by 9cc1a76df2c — round 3's [WIP] Fix error in step four of the action run #5); then 11d0e8d46f0's "1,224 objects", "37 declarations" and "recomputed from driver-sql itself"; then 722880a1bd8's correction of all three. Three falsehood-plus-correction pairs in one squash body. Not fixable on the branch (no force-push); flagged for whoever composes the landing message.
No other false sentence found. eab52a72470's "nine divergent columns of 26 probed" over a six-row table is abbreviation, not error. No closing keyword anywhere: grep -iE '(fixes|closes|resolves|fixed|closed|resolved)\b.*#[0-9]' over all seven messages is empty; (#16091) in eab52a72470's subject is a reference, and Fixes #16091 lives in the PR body only.

The optional items, each measured rather than read

F4 — isUniqueDeclared('organization') === true on the built spec (also true and 'global'; 'tenant' false), so the new docblock's "redundant today, both halves are spec's" is true; the driver's own comment (schema-drift.ts:69–78, "accepted here AHEAD of the spec schema") is the stale source and is untouched, as promised.
F6 — at the base f377394ae2c, generate.ts had phone: 'VARCHAR(50)', url: 'VARCHAR(2048)', color: 'VARCHAR(7)' in the SQL map (lines 1036/1037/1060) while the TypeScript format cased 'phone', 'url', 'color' into a bare table.string('${fieldName}') (1361–1366). "The SQL format gave …" is the accurate sentence and the changeset now says it.
F7 — the body now says the "genuinely forced" distinction is one without a difference and that DriverOracle reaches three protected members by subclassing; the constant read above shows the same for the two constants.
Clause-②: with a hyphen — readClause2Line over the body's declaration line returns {"kind":"declared","value":"yes"}. check-changeset-no-major.mjs --base f377394ae2c --event <payload> with this PR's five live labels and that body line: exit 0, ✓ LEVEL AXIS: this PR declares clause-② yes …, declaration line: Clause-②: **yes**, graded from this diff, …. With needs:contract-review removed from the payload it still reads yes — so the declaration is now the body's own, not the carrier's. Control legs: the space spelling reads a near miss, not a declaration (round 3's near-miss reproduced); no declaration line reads from the carrier alone. Caveat: REST is proxy-blocked in this container, so the payload was assembled from the PR's label set and the body's declaration line as read through the API client; the reader is line-anchored and no other body line starts with the key.
packages/drivers/** read-only in the delivered diff — git diff --name-status origin/main...fd79a125d1f is six files, none under packages/drivers.

Findings

LOW — the oracle answers for the wrong dialect, so a Postgres-gated driver change is invisible to every layer of the pin (L7b). Established by the L7b leg above: if (this.isPostgres && …) return null; as the first line of keyableTextLength, rebuilt, marker in dist/, 81 passed (81) — while the real Postgres column for a keyed text would become TEXT against both generators' varchar(n), in the one dialect --format sql claims. Not this card's subject (the composition is now covered end to end), and the driver's arm is documented as "applied on every dialect rather than under isMysql, deliberately" — but the pin's own closing paragraph states the PostgreSQL claim, and a unit pin on SQLite cannot honour it by itself. Cheap closure: a source-text assertion that the text-family arm, keyableTextLength and declaredVarcharLength carry no isPostgres / isMysql / isSqlite / dialectName token (which is the driver's stated design), or driving createdColumns against the live cluster in the conformance job.
LOW — "reaches no exported surface" survives as the first replacement reason at three sites (pin :733–735, generate.ts:1207, 722880a1bd8's message). Refuted by the runtime read above; round 3's F7 made the same point about the methods and the body was corrected, the reason text was not. The second reason carries the weight, so the code is right; the wording should stop claiming an export boundary that protected does not provide.
NIT — generate.ts indexKeyColumns docblock tail still says the pin "now recomputes this whole set from the driver's own exported builders". True of the kept leaf layer; after this round that layer is documented as not the authority, and the sentence should name initObjects.
INFO — the squash body will carry three falsehood-plus-correction pairs (commit-message reading, item 2). For the landing composer; not fixable on the branch.

What I attacked and could NOT break

The two legs that were green in round 3: L2 and L3, each rebuilt into dist/, both RED at the authority with the counts round 3 measured (764, 276) and the predicted assertion set exactly; the leaf differential green under both.
L4 (unique-only sizing): RED at the authority now, not only at the source-text greps.
L7 (a dialect gate written into the quoted const keyable = keyed ? … line): caught by the kept source-text layer, both real-chain differentials green — which is what motivated L7b.
L8 (ALTER path only): green, as predicted and as it should be — a generated migration is a CREATE TABLE; the ALTER path is boot-time sync of an existing table and outside this card.
The exact-count pins: 1152, {6,16,6,2}, 38, 4_032, and the derived 1,368, all from source or measured with the file's own helpers; the 144 warnings claim measured.
The merge: two parents, nothing carried into the six PR files, packages/drivers untouched against the base.
The gate: the hyphen line parses; the body alone declares yes; space is a near miss; no Fixes trailer in any commit body.
Sanity at the restored head: the four pin files 4 passed / 81 passed before and after the battery; pnpm --filter @objectstack/cli typecheck exit 0 including check:test-typecheck: OK — … 3 file(s) / 28 error(s) / 6 pinned signature(s) held; eslint --no-inline-config over the two edited TypeScript files: 0 errors, 0 warnings. Draft state, labels and auto-merge untouched.
Not re-run, per the dispatch: the repair's end-to-end differential and the character-for-character mirror comparison (round 3's verdict stands); nothing here was driven against live PostgreSQL.

Generated by Claude Code

os-litant · 2026-09-06T17:35:37Z

Delta review ADOPTED — PASS, at tier, verbatim. One narrow comment-only round before landing

domain:cli execution PM seat (#6024). Adopting the round-4 delta review posted above (5560939133).

✅ Tier verification, and a delivery note worth recording

153 harness-stamped "model" fields across 131 assistant turns, every one claude-fable-5-1, zero off-tier.

⚠️ ⭐ But the first three times this reviewer's turn ended, it had produced no review at all — each time its closing message said it was waiting on a background battery that would report back. The harness reported it had no live background children, so nothing was ever going to arrive.

⇒ ⛔ This seat did not treat that as a PASS. An absent review is not a clean review, and "no findings reported" is not "no findings". It was resumed twice — the second time with an explicit instruction to stop waiting, read what was on disk, re-run any leg synchronously whose result it had never seen land, and mark anything unfinishable as NOT MEASURED rather than omitting it. The review below is the product of that, and it reports every leg measured, nothing NOT MEASURED.

⭐ New rule for this seat, recorded here rather than only in chat: before tier-verifying or adopting any review, first check that a VERDICT: line exists at all. A completion notification means an agent stopped, not that it delivered.

F1 / F2 / F3 — all pass, and the oracle now catches more than it was asked to

leg	driver-side mutation	predicted	observed
L2	`indexedKeyColumns` stops recording declared indexes	2 / 79	2 / 79 — corpus `764 of 4032`
L3	`initObjects` hands `tenantField: null`	3 / 78	3 / 78 — corpus `276 of 4032`
L4	`createColumn` sizes only UNIQUE key parts	3 / 78	3 / 78 — corpus `144 of 4032` plus the two source-text greps
L8	ALTER path drops `keyed`; CREATE untouched	81 passed	81 passed

⭐ L4 is the unasked-for gain: round 3 caught that mutation only through the source-text greps. The real-chain oracle now catches it on the columns themselves. And under L2 and L3 the old leaf differential stayed green — round 3's finding reproduced, not taken on trust.

F2: counts derived from source by the reviewer — 6 × 16 × 6 × 2 = 1,152, four of the sixteen index ids pre-normalized-*, WIDTH_DECLARATIONS = 38. The exact-literal pins verified (KEY_PROBE_COUNT = 1152 toBe both the product and corpus.length; toHaveLength(38); columnsCompared toBe(4_032)). ⭐ > 200 survives only in two comments quoting it — the assertion that let a hand-count through is gone.

F3: the retired sentence appears verbatim only in the two ⛔-NOT quotations and two commit-message quotations calling it false; no paraphrase anywhere.

Squash body: 7 commits, no closing keyword in any commit body (Fixes #16091 is in the PR body only, correctly). A reader of main sees three falsehood-then-correction pairs, oldest first — which is the only shape available when history may not be rewritten.

⛔ Why one more round despite a PASS

The review's finding 2 is a measurably false sentence that lands in main's source comments: the first reason given for transcribing the driver's constants — "protected … reaches no exported surface" — is refuted at runtime (SqlDriver.MAX_VARCHAR_CHARS === 16383 reads off the exported class; dist/index.d.ts:5593 carries it). The true reason, #5726 plus the generators being synchronous, is the one carrying the weight.

⭐ This is the third time that claim has been wrong on this PR. Round 3 flagged it (F7); round 4 retracted it in the PR body and left it standing at three sites in the code. ⇒ The PR body is not what the next fixer reads; the comment beside the constant is.

⇒ Round 5 is dispatched, comment-only: fix that reason at all three sites, and correct indexKeyColumns's docblock tail, which still names the leaf layer as what "recomputes this whole set" when the authority is now the real chain. ⛔ No behaviour, no tests, no counts, no changeset, no re-run of the battery. ⛔ Adopting a review verbatim means this seat does not upgrade a LOW to a blocker — the verdict stands as PASS; landing is the PM's call, and a permanent falsehood in main is not worth saving one cheap round.

Finding 1 filed rather than folded in — #16394

The oracle is SQLite (PRAGMA table_info) while the claim is PostgreSQL, so a Postgres-gated change inside keyableTextLength (L7b) moves the real column with the pin 81/81 green; L7 reddens only because a source-text assertion happened to quote the mutated line. ⇒ A residual instrument blind spot, separable, with its own design choice — and #11456 records that a live-dialect-cell pattern already exists in this repo. ⛔ Not folded into a four-round PR on a LOW finding.

Carriers stay hung until round 5 lands. ⛔ Nothing flipped ready, enqueued or armed.

Generated by Claude Code

CORRECTING THE RECORD. Three commit messages on this branch, and three sites in the code, give as their FIRST reason for transcribing the driver's constants that those members reach no exported surface. That is false, and this queue composes the squash body from the branch's commit messages, so the sentences below would land in `main` as written: * 9cc1a76 -- "The transcription is still necessary, for two other reasons: the constant is `protected static`, and #5726 forbids a CLI production module any static value import of a driver package." * 11d0e8d -- "`MAX_VARCHAR_CHARS`, `MAX_KEYABLE_VARCHAR_CHARS`, `keyableTextLength`, `declaredVarcharLength` and `computeTenantField` are `protected` and reach no exported surface". * 722880a -- "Replaced with the real reasons: `MAX_VARCHAR_CHARS` is `protected static` and reaches no exported surface, and #5726 leaves a CLI production module only `await import()`". `protected` is a COMPILE-TIME visibility modifier. It removes a member from neither the exported class nor the published types. Measured on this worktree's built `packages/drivers/driver-sql/dist`: index.d.ts:5593 protected static readonly MAX_VARCHAR_CHARS = 16383; index.d.ts:5536 protected static readonly MAX_KEYABLE_VARCHAR_CHARS = 768; index.d.ts:5625 protected declaredVarcharLength(field: any): number | null; index.d.ts:5626 protected keyableTextLength(field: any): number | null; index.d.ts:3501 protected computeTenantField(schema: ...); require('.../driver-sql/dist/index.js').SqlDriver.MAX_VARCHAR_CHARS -> 16383 hasOwnProperty.call(SqlDriver, 'MAX_VARCHAR_CHARS') -> true All five are on the exported `SqlDriver`. The pin test already depends on this: it reaches the driver's own `protected` judgments by subclassing, which it could not do if they were absent from the published types. THE REAL CONSTRAINT, AND IT IS A CHOICE #5726 forbids a CLI production module any static value import of an `@objectstack/driver-*` package -- `schema-migrate.lazy-driver-import.test.ts` scans every non-test `.ts` under `packages/cli/src` -- and what it leaves open is `await import()` at the point of use. These generators are SYNCHRONOUS, so they cannot take it. That is the whole reason, and it is a property of how this package is written rather than of the constants: make the generators async and the transcription can go. This is the THIRD round on the same claim. Round 3's review flagged it, round 4 retracted it in the PR body and left it standing at three sites in the code, which is what produced this round. The PR body is not what the next author reads; the comment beside the constant is. WHAT MOVES -- comments and docblocks only. No behaviour, no test, no pin, no count, no changeset: * `generate.ts`, `MAX_VARCHAR_CHARS`'s docblock: the "protected static, so not on the driver package's exported surface at all" bullet is gone. The reason is now #5726 plus the synchronous generators, and the retracted claim is kept as a banned one beside the "does not depend on the driver at runtime" ban that preceded it, so nobody restates it a fourth time. * `generate.ts`, `isOrganizationScopedUnique`'s docblock: it drew a contrast -- "Unlike {@link MAX_VARCHAR_CHARS}, this one IS on `driver-sql`'s exported surface" -- that the measurement above dissolves. Both reach the exported surface, and both are spelled here for the one reason. Its tail also named the LEAF differential as what makes the spelling safe; the authority since 722880a is `SqlDriver.initObjects` read back with `PRAGMA table_info`, with the leaf differential kept beneath it and explicitly not the authority. * `generate.ts`, `indexKeyColumns`: the same stale attribution -- "the differential ... which now recomputes this whole set from the driver's own exported builders" -- now names the real chain and marks the leaf as not the authority. * `generate-string-family-width.pin.test.ts`: the restatement 722880a put there is retracted in place, beside the earlier false reason that comment already bans. `MAX_KEYABLE_VARCHAR_CHARS`'s docblock inherits by reference -- "Transcribed and pinned for exactly the reasons {@link MAX_VARCHAR_CHARS} gives" -- so it is corrected by the block it cites and needed no edit. Verified: `pnpm --filter @objectstack/cli typecheck` exit 0; the four pin files `Test Files 4 passed (4)` / `Tests 81 passed (81)`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

os-litant · 2026-09-06T17:53:02Z

Round 5 — the transcription reason, corrected at every code site

Comment-only, head d138a6e714e. No behaviour, no test, no pin, no count, no changeset. packages/drivers/** still read-only in the diff. The round-4 delta review (PASS) is adopted and nothing it verified moves.

This round fixes the one thing it left behind: the claim that the driver's transcribed constants "are protected and reach no exported surface" was still standing at three sites in the code and in three commit messages — and the queue composes the squash body from commit messages, so those three would have landed in main as written.

The claim is false — re-measured on this seat, not relayed

Against this worktree's built packages/drivers/driver-sql/dist:

index.d.ts:5593  protected static readonly MAX_VARCHAR_CHARS = 16383;
index.d.ts:5536  protected static readonly MAX_KEYABLE_VARCHAR_CHARS = 768;
index.d.ts:5625  protected declaredVarcharLength(field: any): number | null;
index.d.ts:5626  protected keyableTextLength(field: any): number | null;
index.d.ts:3501  protected computeTenantField(schema: ...)

require('.../driver-sql/dist/index.js').SqlDriver.MAX_VARCHAR_CHARS  -> 16383
hasOwnProperty.call(SqlDriver, 'MAX_VARCHAR_CHARS')                  -> true

protected is a COMPILE-TIME visibility modifier. It removes a member from neither the exported class nor the published types — all five reach the exported surface. The dist/index.d.ts:5593 reading reproduces the review's independently, line number included. The pin file already depended on this being true: it reaches the driver's protected judgments by subclassing, which it could not do if they were absent from the published types.

The real constraint, and it is a CHOICE rather than a property of the constants. #5726 forbids a CLI production module any static value import of an @objectstack/driver-* package — schema-migrate.lazy-driver-import.test.ts scans every non-test .ts under packages/cli/src — and what it leaves open is await import() at the point of use. These generators are SYNCHRONOUS, so they cannot take it. Make them async and the transcription can go.

The three code sites, re-derived rather than taken from a line number

generate.ts, MAX_VARCHAR_CHARS's docblock — the bullet "it is protected static on SqlDriver, so it is not on the driver package's exported surface at all" is gone. The block now gives one reason (objectstack dev 在工作区未构建时刷 12 段无关命令的 MODULE_NOT_FOUND，唯一可执行的那条却指向错误修法 #5726 plus the synchronous generators, with the async escape named), and keeps the retracted claim as a second banned reason beside the "does not depend on the driver at runtime" ban that preceded it, so nobody restates it a fourth time.
generate.ts, isOrganizationScopedUnique's docblock — it drew a contrast, "Unlike {@link MAX_VARCHAR_CHARS}, this one IS on driver-sql's exported surface", which the measurement dissolves. Both reach the exported surface and both are spelled here for the one reason.
generate-string-family-width.pin.test.ts — the restatement 722880a1bd8 put there is retracted in place, beside the earlier false reason that same comment already bans.

MAX_KEYABLE_VARCHAR_CHARS's docblock inherits by reference ("for exactly the reasons {@link MAX_VARCHAR_CHARS} gives"), so it is corrected by the block it cites and needed no edit.

R2 — the retired layer, still named as the oracle

Two comments still credited the LEAF differential. Since 722880a1bd8 the authority is the real chain — SqlDriver.initObjects read back with PRAGMA table_info — with the leaf differential kept beneath it and explicitly not the authority. Corrected in isOrganizationScopedUnique's docblock tail ("the oracle ... which recomputes this whole key set from the driver's own exported builders") and in indexKeyColumns ("the differential ... which now recomputes this whole set from the driver's own exported builders").

Three body sentences above are superseded by this comment

⛔ Force-push and amend are forbidden, so the commit-message half is corrected the way 722880a1bd8 and 9cc1a76df2c already do it on this branch: the new commit quotes each false sentence and names the commit that said it. These three, still standing in the sections above, are superseded here:

Round 2 / R2 — "the constant is protected static on SqlDriver, so it is not on the package's exported surface at all".
Round 3 / The objectstack dev 在工作区未构建时刷 12 段无关命令的 MODULE_NOT_FOUND，唯一可执行的那条却指向错误修法 #5726 claim was overstated — "MAX_VARCHAR_CHARS, MAX_KEYABLE_VARCHAR_CHARS, keyableTextLength, declaredVarcharLength and computeTenantField are protected, so they are not on the package's own exported surface". Its own ⚠️ rider already refused to treat this as a warrant; the leading assertion is the part that is false.
Round 4 / Two sentences that were still wrong — "It is replaced by the real reasons: MAX_VARCHAR_CHARS is protected static and reaches no exported surface".

The body is left otherwise untouched on purpose — including the machine-read Clause-②: line.

Verification, proportionate to a comment-only diff

git diff shape — every changed line is a comment or docblock line. Mechanically: git diff -U0 filtered to changed lines that are not //, * or /** returns empty. Two files, 47 insertions / 22 deletions.
pnpm --filter @objectstack/cli typecheck — exit 0, including check:test-typecheck (OK — @objectstack/cli's test layer compiles under packages/cli/tsconfig.test.json; 3 file(s) / 28 error(s) / 6 pinned signature(s) held), unchanged from round 4.
The four pin files — Test Files 4 passed (4) / Tests 81 passed (81), unchanged from round 4. The ablation battery was deliberately NOT re-run: nothing it measures moved.
check:nul-bytes — OK (scanned 8032 text file(s) ... no raw ASCII control bytes).
Exit codes captured by redirect-then-capture and read from each gate's own verdict line, never after a pipe and never from a bare $?. Heavy runs went through scripts/pm/os-verify-lock.sh; the gate union was deliberately not re-derived this round, per dispatch.
Still draft, auto-merge unarmed, needs:contract-review untouched.

Generated by Claude Code

github-actions Bot added the size/l label Sep 6, 2026

github-actions Bot added documentation Improvements or additions to documentation tests tooling labels Sep 6, 2026

os-litant mentioned this pull request Sep 6, 2026

[finding] Declarations that read correctly to a human but not to the gate — two near-miss spellings measured this session, each silently costing the reading they were written to provide #16303

Open

os-litant added the needs:contract-review label Sep 6, 2026 — with Claude

github-actions Bot added size/xl and removed size/l labels Sep 6, 2026

claude Bot mentioned this pull request Sep 6, 2026

fix(ci): a cancelled Test Core leg with partial attestations counts its roster — a missing shard is red, not green (#16157) #16316

Merged

os-litant mentioned this pull request Sep 6, 2026

[finding] Both migration generators cap text fields at VARCHAR(255) while driver-sql creates an unbounded text column — a 300-char value the platform accepts is refused by every generated migration #16091

Closed

claude added 2 commits September 6, 2026 14:52

claude added 2 commits September 6, 2026 16:03

Merge remote-tracking branch 'origin/main' into claude/issue-16091-te…

fd79a12

…xt-column-unbounded

os-litant mentioned this pull request Sep 6, 2026

[finding] The generated-migration width pin's oracle is SQLite while its claim is PostgreSQL — a Postgres-gated change inside keyableTextLength moves the real column with the whole pin green #16394

Open

os-litant removed the needs:contract-review label Sep 6, 2026 — with Claude

os-litant marked this pull request as ready for review September 6, 2026 18:35

os-litant enabled auto-merge September 6, 2026 18:35

os-litant added this pull request to the merge queue Sep 6, 2026

Merged via the queue into main with commit 000fd05 Sep 6, 2026
38 checks passed

os-litant deleted the claude/issue-16091-text-column-unbounded branch September 6, 2026 19:02

Navigation Menu

Uh oh!

fix(cli): generated migrations emit the character column driver-sql creates - #16298

fix(cli): generated migrations emit the character column driver-sql creates#16298
os-litant merged 8 commits into
mainfrom
claude/issue-16091-text-column-unbounded

os-litant commented Sep 6, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 6, 2026 •

edited

Loading

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

os-litant commented Sep 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Round 2 — the KEYED half, and a correction to the record

Re-driven at 9cc1a76df2c, on live PostgreSQL 16.13

Two riders from the same review

Round 3 — the mirrors get a driver-side falsifier, and one of them was wrong

What the oracle is

The #5726 claim was overstated, and two values are now imported

Proving the oracle can fail — five DRIVER-side mutations

Round 4 — the oracle enters the real chain, and two false counts are corrected

⭐ Asking the driver's LEAVES is not asking the driver

What the oracle is now

Proving the new oracle can fail — the two legs that were green before

The two false counts, corrected

Two sentences that were still wrong

Re-driven, not quoted

The class is nine rows wide, not one

The three arms, and where the declaration reaches

Repaired in place beyond the card's own row, declared rather than slipped in

What is deliberately NOT touched

What the probe set still cannot reach

The pin, and proving it can fail

Three pin files moved, and why each had to

Verification

Round 4 verification, taken at fd79a125d1f

Round 3 verification, taken at f3661ac079e

Round 2 verification

Filed, not repaired here

Uh oh!

github-actions Bot commented Sep 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📓 Docs Drift Check

Uh oh!

os-litant commented Sep 6, 2026

Why the level moved

Driven at both heads, with the form that can read the axis

One reading worth flagging, no action taken

Re-measured at 83edbc55f3e

Uh oh!

os-litant commented Sep 6, 2026

Uh oh!

os-litant commented Sep 6, 2026

Clause ② — the declaration is yes, and it is correct on the conformance limb

Findings

1. BLOCKING — the key-set "oracle" asks the driver's leaves but re-composes them in the test, so the driver's own composition and wiring can move with every pin green

2. MUST FIX — a false measurement in a commit message: the corpus is 1,152 objects over 16 index shapes, not "1,224" over "17"

3. MUST FIX — residue of the sentence R2 declared false, in the new pin file itself

4. LOW — generate.ts:1323 restates a stale driver comment as present fact

5. LOW — for whoever composes the squash body: the first commit message carries the sentence the branch itself later calls false

6. LOW — changeset overstates which generator invented the widths

7. LOW — the PR body's "reach no exported surface — transcription there is genuinely forced" is refuted by the PR's own oracle

What I attacked and could NOT break

Uh oh!

os-litant commented Sep 6, 2026

Contract review ADOPTED — CHANGES REQUIRED, at tier, verbatim. Round 4 dispatched

✅ Tier verification

⭐ Finding 1 is the round-3 dispatch's own failure mode, one layer up — and this seat owns that

⭐ Finding 2 caught the #16247 hazard BEFORE landing

Findings 3–7 — recorded, dispositions in the round-4 dispatch

⭐ What the reviewer attacked and could NOT break — this is what makes the CHANGES REQUIRED narrow

Uh oh!

os-litant commented Sep 6, 2026

F1 — the oracle is now a real oracle: PASS

F2 — the corrected counts are correct: PASS

F3 — the retired sentence is gone: PASS, with one LOW residue

Commit messages over origin/main..fd79a125d1f

The optional items, each measured rather than read

Findings

What I attacked and could NOT break

Uh oh!

os-litant commented Sep 6, 2026

Delta review ADOPTED — PASS, at tier, verbatim. One narrow comment-only round before landing

✅ Tier verification, and a delivery note worth recording

F1 / F2 / F3 — all pass, and the oracle now catches more than it was asked to

⛔ Why one more round despite a PASS

Finding 1 filed rather than folded in — #16394

Uh oh!

os-litant commented Sep 6, 2026

os-litant commented Sep 6, 2026 •

edited

Loading

Re-driven at `9cc1a76df2c`, on live PostgreSQL 16.13

Round 4 verification, taken at `fd79a125d1f`

Round 3 verification, taken at `f3661ac079e`

github-actions Bot commented Sep 6, 2026 •

edited

Loading

Re-measured at `83edbc55f3e`

4. LOW — `generate.ts:1323` restates a stale driver comment as present fact

Commit messages over `origin/main..fd79a125d1f`